CMake Port/Workshop 2019 11
Qt CMake Workshop 2019-11 day 1 notes
Notable things done since last workshop
Adapted API calls to start with qt_
Improved conversion scripts
Adapted CMake static plugin API in wip/cmake to conform to the API in qtbase/dev
Ported qtremoteobjects, qtscxml, almost qtwayland
Android qtbase builds in Coin, other modules WIP from liqi
Things that have not yet been adapted since last workshop
Not all features are exported yet (public and private CONFIG+=), blocks qtmultimedia
No qtConfig() equivalent in CMake yet
No qtRequires() equivalent in CMake yet
No building modules with qmake yet
Why find_package(Qt6) instead of find_package(Qt5 VERSION 6.0.0)
Because customer apps will want to find both Qt5 and Qt6 in a single project, which sets Qt5_DIR and Qt6_DIR, thus they need to be separate
Brainstorm further, if we can fix upstream FindQt.cmake in CMake, to use find_package(Qt) instead of find_package(Qt6), currently that finds only qt3 or qt4.
Froglogic wants json files with includes, defines, compiler / linker options, all enabled/disabled features, maybe other things as well
One possible solution, is to continue using qmake to create a sample project, and extract flags
Another, is to create a CMake sample project, and use file(GENERATE) with generator expressions to extract flags
Another is to ask Froglogic to implement the support they need themselves : )
Or talk to Kitware to see if they have any plans to implement something like pkg-config –libs, etc, which could be used for querying info about Qt
No discoverability for features, like configure –help
We should still provide a configure –help, adjusted for cmake, with just the important features, command line arguments
People can use CMake GUI to fine-tune features after configuring Qt
People should embrace to use -DFoo=Bar command line flags, that's also what meson does
People want to use pkg-config for all 3rd party deps on Linux distros, like Gentoo, (implies creation of more Find modules)
If existing CMake package Config.cmake files have bugs, influence distros to fix the bugs, and upgrade to that distro version
When needed, we will have to write the necessary FindFoo.cmake or FindWrapFoo.cmake files (contributions welcome), and those can use pkg-config inside. After we have all the custom find modules written, we can consider adding a feature that forces pkg-config to be preffered
Bumping min CMake version to 3.16 because in order to implement the new "moc –collect-json" functionality, we need the Autogen.json files created by AUTOMOC (both for building Qt and ultimately for consumers of Qt that create qml modules)
The qmake changes are already merged to 5.15 in base and declarative, which means that declarative will fail to build if CMake doesn't support it
Merge qtbase wip/cmake into dev even if it's not yet ready
Can't be done yet due to:
Coin production not having the necessary changes for using our .yaml instructions
Some changes were done in .pro files that break tests when building with qmake
Provide CMake mkspecs / toolchain files that would pass/provide the same compiler/linker flags when building a Qt app / library, which were used while building Qt in Coin? (Something froglogic brought up)
Use case is to have exact same compiler / flags, to build some Qt extension, otherwise binary incompatible (think –asan flags, or special flags for inserting probes)
Maybe compile_commands.json is enough? Please provide more feedback? In case everything fails, we can meet face2face
Require python for building qtcore? Use it instead of C++ for the moc --collect-json functionality
No need, PoC done in Python, switch to C++ is ongoing
Public CMake API
Provide both qt5_ and qt6_ functions public CMake api functions.
Also provide non-numbered qt_ functions, which are configurable by setting some variable like set(QT_DEFAULT_QT_VERSION).
Provide the qt_ functions BOTH in qt5.15 and qt6.0.
If you find_package(Qt5), and do not specify the default version, set default version to 5.
If you find_package(Qt6), and do not specify the default version, set default version to 6.
If you find_package both, last one wins.
QT_DEFAULT_QT_VERSION should NOT be set as a cache variable, so that you can use different default version is different subdirs of the same overall project.
We should set(CMAKE_AUTOMOC ON) automatically both when calling find_package(Qt5) or find_package(Qt6).
Discuss with KDE how we can handle add_executable and Android, so we don't have to introduce add_qt_executable.
KDE handles this by overriding CMAKE_CXX_LINK_EXECUTABLE for applications, to actually create a dynamic library even if add_executable was called https://phabricator.kde.org/source/extra-cmake-modules/browse/master/toolchain/Android.cmake
But the judgement is still out on whether it's a bad thing to actually provide an add_qt_executable, or add_qt_application.
KDE also uses the CMake provided toolchain for Android, rather than the Google provided one.
KDE also overrides various default variables that they think CMake got wrong, and thus were made more user friendly, some of them here https://phabricator.kde.org/source/extra-cmake-modules/browse/master/kde-modules/KDECMakeSettings.cmake
What should we document
Document internal and external CMake API for building Qt
Migrating from Qt 5 to Qt 6 CMake API
Need to discuss further
Regarding the minimum required CMake version
Try to use a CMake version which will be in 20.04 LTS, so try to get Kitware to release 3.17 early, so it can get in the next LTS
After Qt 6.0, we might consider bumping minimum CMake version with each Qt LTS release if necessary