I work on build systems a fair bit, and this is something I thought others might benefit from. I went through quite a bit of code in our projects that did not do things the “right way”, and it wasn’t clear what that was to me at first. Qt 5 improved its integration with CMake quite significantly – moving from using the qmake command to find Qt 4 components in a traditional CMake find module to providing its own CMake config files. This meant that instead of having to guess where Qt and its libraries/headers were installed we could use the information generated by Qt’s own build system. This led to many of us, myself included, finding Qt 5 modules individually:
|
1 2 |
find_package(Qt5Core REQUIRED) find_package(Qt5Widgets REQUIRED) |
This didn’t feel right to me, but I hadn’t yet seen what I think is the preferred way (and the way I would recommend) to find Qt 5. It also led to either using ‘CMAKE_PREFIX_PATH’ to specify the prefix Qt 5 was installed in, or passing in ‘Qt5Core_DIR’, ‘Qt5Widgets_DIR’, etc for the directory containing each and every Qt 5 config module – normally all within a common prefix. There is a better way, and it makes many of these things simpler again:
|
1 |
find_package(Qt5 COMPONENTS Core Widgets REQUIRED) |
This is not only more compact, which is always nice, but it means that you can simply pass in ‘Qt5_DIR’ to your project, and it will use that when searching for the components. There are many other great features in CMake that improve Qt integration, but I want to keep this post short…
I very much agree, I have been doing this for a little while. I also believe it should be preferable because it will insure that all COMPONENTS will belong to the same Qt5 package: I once needed the component WebKit which was missing from one package, but was present in another one. With the old way, CMake automatically found each component from the first package, but also the webkit component from the second package, and I obviously got no warnings and nice linking issues later on. By looking for Qt5 like you describe, it would indeed signal that the WebKit component was missing from that first package.
One more situation that I’ve found this to be helpful is when adding another Qt5 module dependency to your CMake project or re-configuring. If CMAKE_PREFIX_PATH points to a different location than the one already set by Qt5_DIR in the CMake cache, it could lead to linker issues. Looking for components from the Qt5_DIR set in the cache eliminates this.
Maybe both the CMake and Qt documentations should then be updated. They use one find_package() per Qt module in their examples and fail to mention that a find_package(Qt5) exists.
– https://cmake.org/cmake/help/v3.7/manual/cmake-qt.7.html
– http://doc.qt.io/qt-5/cmake-manual.html
Agreed, both are harder than writing a blog post, but I will follow up in both places. The Qt documentation looks harder to update, but I am pretty sure I can take care of CMake.
There is a merge request for CMake, https://gitlab.kitware.com/cmake/cmake/merge_requests/226, I still need to look into updating this for Qt’s documentation.
I’ve stumbled on this article while searching for alternatives for setting the CMAKE_PREFIX_PATH approach and I’ve given it a try, but unfortunately it does not work. Apparently cmake looks for a FindQt5.cmake file but Qt actually does not distribute it. Thus, it doesn’t work.
The FindQt5.cmake is the “old way”, and it is still searched for. Qt 5 distributes CMake config files, such as Qt5Config.cmake that contain paths, macros, functions, etc. They are unfortunately a little deeper in the tree, so you would have to set Qt5_DIR to “/usr/lib64/cmake/Qt5” in my case. I use this approach on Windows, macOS, and Linux. The reduction in Qt5*_DIR variables, and the assurance that all modules come from the same Qt5 is worth it.