[CMake] Code and API review request for Qt5 CMake files

Stephen Kelly steveire at gmail.com
Fri Feb 24 09:34:36 EST 2012


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.kelly 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




More information about the CMake mailing list