View source for CMake Port/Workshop 2019 11

[[Category:QtCS2019]]
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