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 <step...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development