Please document and streamline the behaviour of how to en-/disable support and features at build time - and save/summarize config in unified way

The way of enabling / disabling support/features when building qt6 modules – and/or controlling what an official qt-module has enabled/disabled and is going to be linked against or not – is completely inconsistent across modules and at least partially absolutely non-transparent and/or counter-intuitive.

Especially, as multiple times a certain build config got me reasonably far, only to realise down the road, that a sub-sub-module requires a base package being configured with a certain optional undocumented feature, which might not even have a switch to turn on and off, but depends on some 3rd party lib being present in the toolchain/environment and auto-detected (or not) during build time.

So, here's my journey:

First of all, it seems we get quite far with a very minimal config for host builds of qt6base and qt6declarative:

qt6base for the host compiles fine (gui disabled, statically linked), qt6base target (shared) compiles fine, too.

qt6declarative for the host compiles fine (again as static build), qt6declarative for the target appears to build (again as shared) fine, too.

Turns out: that way of building, the qt6declarative build only results in a not-really-useful one, with QtQuick.so not being built at all.

That is due to the binary bin/qsb not being found during build time, which is part of the qt6shadertools package and needs to be built for the host in order do be used during the qt6declarative target build in order to actually build QtQuick.so. At least this is hinted by a warning (though, I still don't think the wording is enough to actually understand the necessity of qt6shadertools being present for a functional build): https://bugreports.qt.io/browse/QTBUG-136446?focusedId=882914&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-882914

Suggestion: make clear qt6shadertools is a necessity for a working qt6declarative (target-)build (including QtQuick).

Building qt6shadertools for the host, though, requires the qt6base host build to have the GUI-feature enabled. So back to square one – reconfiguring and -building qt6base for the host, then target.

Suggestion: clarify qt6base host build without GUI support only gets you that far.

Then rebuilding qt6declarative for the host, then for the target – bin/qsb being found and used this time. While build is now getting further, its eventually failing again – with: host tool bin/qmltime not being found.

bin/mltime is a host tool which should be built as part of the qt6declarative host build – but isn't in my case.
Scrolling through the CMake files reveals: bin/qmltime is only built when qt6declarative was built with shared libs enabled (remember, I built it statically): https://github.com/qt/qtdeclarative/blob/6.9.0/tools/CMakeLists.txt#L37). (Why is that the case, anyway?).

So, rebuilding qt6declarative for the host with support for shared libs now, resulting in lot's of other build (mostly linking) issues, which way too late I realised, can be mitigated by also switching building qt6base for the host with shared libs here – so essentially switching to shared-lib-builds for all host projects (incl. qt6base) now.

Chatting with involved Qt folks made me realise I shouldn't even try building the host variants statically. Why is this an option though and nowhere mentioned not to use then?

Suggestion: making clear that host builds with QT_BUILD_SHARED_LIBS=OFF is most likely not what one wants, preventing build of essential host tools.

So, again, back to square one: Building qt6base for the host with QT_BUILD_SHARED_LIBS=ON (and GUI support). Then qt6base for the target. Then qt6shadertools for the host (building bin/qsb). Then qt6shadertools for the target. Then qt6declarative for the host (incl. bin/qmltime this time, yay!). Then qt6declarative for the target (now also producing QtQuick.so)

So now we have qt6base for host and target with GUI support, qt6shadertools for host (with qsb as host tool) and target as requirement for building QtQuick and qt6declarative with QtQuick (using bin/qsb) for host and target – and all builds compiled with QT_BUILD_SHARED_LIBS=ON.

Next module: qt6virtualkeyboard. During its cmake run, it mentions it can't find QtMultimedia and vkb_hunspell, hence respective support will be disabled.
For hunspell I can set INPUT_vkb_hunspell to ON/OFF to explicitly enable or disable that feature.

A similar option to explicitly enable/disable multimedia support, though, appears to be missing, providing no way to make sure:

• the build fails when we want multimedia support but it can't be found
• we build without multimedia support, even if it's present in the current toolchain

In the current way we build qt6virtualkeyboard with unpredictable results: depending on whether the toolchain signals having qt6multimedia installed or not, the qt6virtualkeyboard will have support or won't.

At least its cmake run produces a summary, indicating whether support for multimedia will be compiled in or not, which isn't always the case.. but we will get there in a moment.

qt6virtualkeyboard needs qt6svg. Easy, just building qt6svg now. Now qt6virtualkeyboard complains about the host tool bin/svgtoqml not being found.

That binary is being built as part of the qt6declarative host build, but only built when qt6svg was found at build time!

I checked the qt6declarative source: it just silently uses qt6svg and builds svgtoqml when the toolchain signals qt6svg being present. There is absoluteliy nothing, no variable, no switch, not even a hint that I might want to have qt6svg present for the qt6declarative (host-)build: https://github.com/qt/qtdeclarative/blob/6.9.0/tools/CMakeLists.txt#L69

Again, such code/behaviour results in unpredictable builds, solely influenced on whether qt6svg is present in the toolchain at (host-)build time of qt6declarative or not. This time, not even a statement during build that support for SVG is en- or disabled, no mention on configure status / CMakeCache files.

Suggestion: Please do not silently use or not use libraries solely based on auto-detection, without any documentation, without any flags allowing the user to enforce certain build behaviour - and without any config/build info stored to later on check how / with(out) which support the project got built.

So back again: Re-building qt6declarative for the host while qt6svg being present, so the host tool bin/qmltosvg is being built along, which is a requirement for building qt6virtualkeyboard.

This is where I'm at right now and given the experience I highly doubt that's the end. The next module will most likely fail or not compile in essential things, due to some other feature in qt6base or qt6declarative being disabled or some 3rd party lib during whatever other build wasn't found.

That documentary of my journey cross-compiling Qt6 completely excludes the "qmake and its mkspecs are dead, but qmake and its mkspecs are still necessary – for host and target"-mess: https://bugreports.qt.io/browse/QTBUG-136244

Maybe this documentary provides some help for folks running into the same issues.

Best case scenario, though, would be: behaviour of en-/disabled support getting documented and unified - tl;dr:

1. optional functionality should be allowed to get explicitly en- and/or disabled
2. save / print the configuration of / before the build in a unified way (listing all options and whether going to be being build with or without respective support)
3. do not silently use / link against libraries if found or not if not found
4. discourage from certain (host-)build options which most likely result in a non-sufficient build (static host builds, disabled gui support, etc)
5. document build options/flags/varieties!