[Development] Installing Qt5Config.cmake from the Qt repo?

[Thiago Macieira]

On Wednesday, 2 de November de 2011 13:38:15 Stephen Kelly wrote:
> > However, let me make a suggestion: use macros, not variables. We've run
> > into this problem before in Qt 4 where CMake did not add the -D macros
> > that qmake did and then some results were different (unit tests, for
> > example).
> I might be missing some context here. You're talking about building Qt with
> -DSTRICT_ITERATORS or whatever, and then using cmake to build a project with
> that Qt, but then it didn't automatically use the -DSTRICT_ITERATORS
> itself? Or are you talking about something else entirely?
> 
> Could you expand on the probelms you encountered?

QtTest depends on QT_GUI_LIB being defined or not and changes the class that it 
creates for QTEST_MAIN. In Qt 5, with three Application classes, this is going 
to be even more important.

If you link to a Qt module named Foo, you must do:
	-I$QTDIR/include/QtFoo -DQT_FOO_LIB
	-L$QTDIR/lib -lQtFoo

The -D option has been missing in CMake.

> qt5_add_module could be implemented to do the public and private linking per
> target. The cmake 2.8.7 syntax for that would be
> 
> target_link_libraries(mylib
>   LINK_PUBLIC ${Qt5Declarative_LIBRARY}
>   LINK_PRIVATE ${Qt5Xml_LIBRARY}
> )

LIBRARY or LIBRARIES? QtDeclarative requires QtCore and QtGui.

I hate that CMake has this plural problem. Make *everything* plural, even when 
there's only one library. Or better yet, provide a macro to ease development 
-- the variables are to be used if some other framework cannot use the 
qt5_add_* macros.

> However, there is currently no way to add target specific include
> directories (though it could probably be pushed along
> http://www.cmake.org/pipermail/cmake/2007-June/014386.html)
> 
> But how does this solve any issues with -DAnything?

That's why I'm saying "don't use target_link_libraries".

> > Another benefit is that I don't have to remember to list which modules I
> > want in find_target. They should be automatically gathered from the
> > qt5_add_module commands -- like qmake.
> 
> In my current branch, this already works:
> 
> find_package(Qt5 COMPONENTS Declarative)
> 
> # Can now use Qt5Declarative Qt5Core and Qt5Gui.
> # The dependencies are already found by Qt5Config.cmake.
> 
> So I think that's another 'Done'.

Duplicated work. If you change your code, you need to update two places: where 
you add the module and where you tell CMake to search for it. I'd like the 
tool to help me.

> > Unlike qmake, if I want to decide
> > whether to add some code based on the presence or absence a dependency,
> > then I'd verify some variables set by FindQt5.cmake.
> 
> s/FindQt5.cmake/Qt5Config.cmake/ I suppose.

Yes and no. Yes, the variables come from the config file. No, because I don't 
care where they come from or if they were detected. That's an implementation 
detail. What I care is that find_package(Qt5) sets the variables -- and CMake 
runs FindQt5.cmake if I do that.

> So, yes, you would be able to do:
> 
> find_package(Qt5 COMPONENTS Declarative)
> 
> if (Qt5Gui_FOUND)
>   # Do something
> endif()
> 
> if that's what you mean?

I'd prefer:

> Or do you mean
> 
> find_target(Qt5)
> 
> add_library(mylib SHARED ${mylib_SRCS})
> qt5_add_module(mylib PUBLIC Core Gui Declarative PRIVATE Xml)
> find_package(Grantlee)
> if (Grantlee_FOUND)
>   qt5_add_module(mylib PRIVATE Script)
> endif()
> ?

Something close to that, though the testing would be for e.g. QtWebKit. 
FindQt5.cmake would set the variables for all Qt 5 modules found, so I can 
enable/disable portions of my codebase depending on what was found.

What I don't disable becomes mandatory.

> > The above is only missing a listing of headers so that qt5_add_module
> > knows
> > what to moc. I don't know how that is implemented these days (qmake's
> > HEADERS += line).
> 
> The easiest way is set(CMAKE_AUTOMOC ON), which will work for Qt5 in CMake
> 2.8.7 (cmake 2.8.6 checks for Qt4). Alex has more details:
> 
> http://blogs.kde.org/node/4495

How does it know which files are my headers? It needs to have a list somewhere, 
which needs to be given to the Qt5 macros. It cannot scan all .h in the 
directory because:

1) some files may be somewhere else
2) some .h may not belong to this target, so their moc outputs shouldn't be 
linked to this target
3) some .h may not belong to any target at all, just legacy stuff we kept
4) some headers may not be named *.h

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111102/7d868942/attachment.sig>