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

[Stephen Kelly]

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)

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

> 
> 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_link_libraries/CMakeLists.txt;h=fdd53eb3497baf333e379aec90568d9f76e70c44;hb=fdd49dad034e99e44a3bd3ab35aa714704af27ff)

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?

> Much simpler and more future-proof. 

It would need work on cmake to add target-specific include directories, but 
that's certainly workable.

> 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). Alex has more details:

http://blogs.kde.org/node/4495



-- 
Stephen Kelly <stephen at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111102/992763f2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111102/992763f2/attachment.sig>