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

Concerns raised

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

Discussion points

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