Qt on CMake Workshop Summary – Feb ’19 - Porting Qt to the CMake build system
14.02.2019
Intro
Last Monday and Tuesday a few brave souls from both the Qt Company and KDAB gathered together in the KDAB Berlin office premises to work on the CMake build system for building Qt. There was Mikhail, Liang, Tobias, Kai, Simon (QtCompany) as well as Jean-Michaël, Albert, Volker and me (KDAB) sitting together in a tight room, focusing solely on the CMake port of Qt.
Excerpt of the top-level CMakeLists.txt in qtbase.git
All work done so far is out in public and can be checked out on Qt Gerrit.
About the CMake port
To put this a bit more into context, the Qt Project believes that building Qt with CMake is our best bet in Qt6 times and thus a group of people have started to build a CMake build system prototype. KDAB has a track record of helping out with the CMake support in Qt. For instance most of the “Modern CMake”-style support in Qt5 has been implemented by Stephen Kelly. As of today, we’re even largely responsible for maintaining the CMake support of Qt5. Since quite a few of our customers are actually heavily invested in CMake themselves, we’d also like to make sure Qt stays easy to use with it in future. Thus we’re continuing to invest in Qt’s CMake support and would like to help out with the early Qt6 build system exploration happening right now.
The central page where we’re currently collecting the progress made as well as the future roadmap is here: https://wiki.qt.io/CMake_Port
On that page you’ll also learn which branch to check out from Gerrit in order to start playing around with the current state of the Qt/CMake build. Please make sure to have the prerequisites for building the branch (i.e. a current CMake build!).
Workshop Summary
As Simon mentioned in his workshop summary, sent to the qt-development mailing list, we were able to make good progress on multiple fronts the last few days. Let me just outline his notes part of that mail, with some additional comments of my own:
Quoting Simon
- We were able to fix the artifacts of “make install” in qtbase to allow for building an external module (qtsvg) and sample apps. The plan for allowing people to develop apps that work with Qt 5 and Qt 6 is quite simple API wise:
- In your application use either
find_package(Qt5)orfind_package(Qt6) - Always use
Qt::Core,Qt::Gui, etc. for linkage - We want to add the “plain”
Qt::Core,Qt::Gui, targets also to Qt5’s CMake support
- In your application use either
- The script to converting .pro files to CMakeLists.txt is becoming really good. The goal is to convert all scopes and (source) file names correctly. Right now the repo contains incremental conversions with hand-edits.
- We’re working on installing the latest CMake (as required) in the provisioning setup, so that we can get a building CI as soon as possible.
- We were able to verify that cross-compilation works well. The main challenge is ensuring that third-party libraries that used to be copied in src/3rdparty are either installed in the sysroot or can be found outside.
- We discussed and experimented with different ways of making static builds robust. So static builds themselves work already, but what we’re looking into in particular is an automatic way of propagating Qt internal dependencies (such as double-conversion) correctly, to the build process of the application, that is not fragile.
- We added a lot more plugins and platform support libraries to the build process and did many improvements to the finding of external libraries.
More than that
- Additionally we’ve succeeded in generating CMake config files compatible with the current config files generated by the Qt/QMake build
- For instance, we’ve been able to successfully compile KDAB’s GammaRay (which has a rather complex beast of a CMake build system) against the Qt/CMake build of qtbase
- We were able to compile QMake using CMake in order to retain the support of using QMake to compile Qt projects for existing users of Qt/QMake
Outlook on the future
- We’ll investigate ensuring a smooth Qt build process on macOS and Windows platforms for developers
- We’ll add the CMake build system to other Qt modules (thinking of qtsvg (rather simple), qtdeclarative (rather complex))
- We’ll add a super build which takes care of building multiple Qt modules in one go (cf. a top-level build off from qt5.git)
- Test more cross-compilation configurations
- Make sure static builds of Qt are not a pain to deal with for external users (like it is right now)
- Make sure to continuously test the Qt/CMake build using basic CI build support.
- QMake will likely still be around in future Qt6 times, as there’s still a lot of users out there. The difference will just be that QMake itself is built using CMake inside qtbase.git; and QMake’s module .pri files will get generated by CMake instead.
- Obviously exactly the other way around to what it is right now in Qt5/QMake, where QMake generates the CMake config files for CMake!
If you have comments or if you want to help out, please ideally post feedback on the Qt Project infrastructure. Send a mail to the qt-development mailing list or comment on the wiki page dedicated for the CMake port. Or just join us in the IRC channel #qt-cmake on Freenode!
