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

[Alexander Neundorf]

On Wednesday 02 November 2011, Stephen Kelly wrote:
> On Wednesday, November 02, 2011 11:50:11 Thiago Macieira wrote:
> > On Wednesday, 2 de November de 2011 11:26:10 Stephen Kelly wrote:
> > > The use file is a convenience that is relatively common in cmake
> > > modules that  adds includes and definitions etc, but the more direct
> > > way is also possible.
> > 
> > So we go back to what I said: the names of the individual variables are
> > part of the public API of FindQt5.cmake.
> 
> Yes. (I guess)

Yes.

> > 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?

Yes, it should be this issue.
 
> > So the example I had should be instead rewritten to:
> > 
> > project(MyLib)
> > find_target(Qt5)
> > 
> > add_library(mylib SHARED ${mylib_SRCS})
> > qt5_add_module(mylib PUBLIC Core Gui Declarative PRIVATE Xml)
> > 
> > add_executable(tst_mylib NOGUI ${tst_mylib_SRC})
> > target_link_libraries(tst_mylib mylib)
> > qt5_add_module(tst_mylib Test Xml)
> 
> 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}
> )
> 
> (As Qt5Declarative already has Qt5Core and Qt5Gui in its public link
> interface I don't need to specifically add them when linking mylib. My
> unit tests on this are admittedly hard to parse on sight but are quite
> complete:
> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/CMakeCommands/target_lin
> k_libraries/CMakeLists.txt;h=fdd53eb3497baf333e379aec90568d9f76e70c44;hb=fd
> d49dad034e99e44a3bd3ab35aa714704af27ff)
> 
> 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)

In a mail from today on cmake-developers Dave mentioned that they will be 
working on per-target include directories (as target properties) in the near 
future. Maybe already for 2.8.7, probably later.

> But how does this solve any issues with -DAnything?
> 
> > Much simpler and more future-proof.
> 
> It would need work on cmake to add target-specific include directories, but
> that's certainly workable.

Being able to just state "my target Foo uses packages Bar and Blub" is already 
since quite some time on the TODO for cmake, i.e. so that Foo will then link 
against Bar and Blub, and also get the include directories for Bar and Blub 
(and probably also necessary macros).

I'd say this shouldn't be pushed into a Qt5Config.cmake, but we should use 
what will be in cmake (and if possible help with getting it into cmake).
 
> > What's more, since QtCore, QtGui and
> > QtDeclarative are part of MyLib's public interface, anything linking to
> > it automatically inherits them (e.g., qmake's QT += or LIBS += line).
> > The private dependencies are an implementation detail, which may need to
> > be exposed if static linking is being attempted (qmake's QT_PRIVATE +=
> > or LIBS_PRIVATE += line).
> 
> Good point on the static linking stuff. I should test for that in CMake.
> 
> But again, yes, we can do equiavlent in CMake. Part of the advantage of
> using Config.cmake and Targets-*.cmake files is that stuff is much easier.
> (Though not being able to use the cmake executable to generate them means
> that it's harder).
> 
> > 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'.
> 
> > 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.
> 
> 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?
> 
> 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()
> 
> 
> ?
> 
> > 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). 

Yes. CMake will need a small modification to support Qt5 too, but if the 
behaviour of moc stays the same this will be simply to not only check for 
QT4_FOUND, but also QT5_FOUND.

> Alex has more details:
> 
> http://blogs.kde.org/node/4495

Alex