Just forwarding to the cmake users list.
Stephen Kelly wrote: > > Hi there, > > Qt5 generates its own CMake files, which you will be able to use to find > Qt5 and build with it. > > That is, you will port from, eg > > find_package(Qt4 REQUIRED Core Gui Xml) > > to > > find_package(Qt5Widgets REQUIRED) > find_package(Qt5Xml REQUIRED) > > find_package(Qt5Core) is also possible but is not needed because it is a > dependency of at least one of the other requirements already in this case. > > find_package(Qt5) will not work currently (though it can be made to work > now or after Qt 5.0). > > You will then port > > target_link_libraries(foo ${QT_QTCORE_LIBRARIES}) > > to > > target_link_libraries(foo ${Qt5Core_LIBRARIES}) > > etc. > > Or you might use qt5_use_package: > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3083 > > qt5_use_package(foo Core) > # That's it! Nothing more to do. > > The variables all map fairly well. There is also a Qt5Transitional package > which might help with that (If it gets released, which I'm not certain it > will be): https://projects.kde.org/projects/kdesupport/extra-cmake- > modules/repository/revisions/master/entry/modules/FindQt5Transitional.cmake > > The Qt5<module>Config.cmake files are generated and installed by Qt > itself. > > I'd like a review of them by people familiar enough with how CMake works > and an API review from people familiar with how it is used. > > The generation of them is platform specific, and configure options > specific, eg whether you use -framework on mac, whether you use MinGW or > MSVC, whether building with an infix or a namespace. The easiest way for > you to generate the config files is: > > # Note: Don't bother cloning qt5.git unless you already have it. > # That takes forever. > git clone git://gitorious.org/qt/qtbase.git > cd qtbase > ./configure > ls lib/cmake > > Make sure you have at least commit > c470999329ee576038c50573314699f972f48909. > > You can go on to build and test them if you wish. The ctest unit tests are > in qtbase/tests/manual/cmake. These tests are not part of any > multi-platform CI system. > > Compared to the last time I emailed about this, the generated Config files > have become more simple. I discovered that qmake can have conditionals in > its configure_file equivalent. > > Things that work: > * Finding Qt with an infix. > > * Building against Qt with a namespace. > > * Finding statically built Qt (though when linking you have to list the > dependencies yourself currently) > > * Finding a particular version should work as ConfigVersion files are > installed, but I have not tested it. > > Things to review: > > * Are the Config files created correctly for your platform and > configuration? > > * Do the unit tests pass on your platform? > > * Currently there is no Qt5Config.cmake. > Such a thing could probably exist and use the FIND_COMPONENTS to find what > was requested. However, because there is no way to signal from a Config > file that a component was not found (that is, find_package(Qt5 REQUIRED > Gui Xml) might not find QtXml, but Qt5_FOUND would still be true if the > Qt5Config file is found, whether the component is or not), I'm not sure > it's a good idea, or at least it's more complicated. At least, I think > something like qt5_use_package is a better idea anyway. > > We could have a small FindQt5.cmake in CMake which could do that however > maybe. > > * Do you see any issues related to cross compiling? > > * Try my port of the CMake Gui dialog to Qt5, or review the patches (most > of the patches make sense in CMake master anyway IMO): > https://gitorious.org/~steveire/cmake/steveires-cmake/commits/qt5-port > > * API Review - > Do the variable names make sense? For example, to find a regular Qt5Gui, > you use find_package(Qt5Gui) and then you can use ${Qt5Gui_LIBRARIES}. > > To find a Qt which was built with a namespace you use find_package(Qt5Gui) > and then you can use ${Qt5Gui_LIBRARIES}. That is - it's exactly the same. > > To find a Qt that was built with an infix in the library names, you use > find_package(Qt5Gui) and then you can use ${Qt5Gui_LIBRARIES}. That is - > it's exactly the same. > > Is there any reason for it not to be the exact same in all these cases? > > I'd imagine if using an infix-ed Qt, that's an implementation detail. If > using a namespaced Qt, it might be an uninteresting implementation detail. > I'm not really certain of the use-cases for a namespaced Qt and how that > might affect this CMake API. > > * Is anything missing? One thing that is missing is the qt4_automoc macro > (all other macros are available with qt5 equivalents). Alex say's it's > broken. The CMAKE_AUTOMOC feature is a not-completely-source-compatible > replacement. > > > Thanks, > > -- > Stephen Kelly <stephen.ke...@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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake