CXX-Qt does not work in split-Qt installations

[redstrate]

I was working on integrating Rust and a CXX-Qt application into KDE's Craft build/package system, specifically for building an Android application. I managed to get somewhat far, but I'm now hitting a brick wall. This is half-question, half-notes to myself.

Selected qmake binary

I needed to set QMAKE manually, which we do have in the documentation which is extremely helpful. However, it's weird that the qmake you find in CMake (through the Qt::qmake target) can be completely different than what cxx-qt uses by default. In Craft, we have two qmake binaries: one for the host (x86_64) and one belonging to the actual Qt installation used for cross-compilation.

The Qt::qmake targets points to the correct qmake to use, but cxx-qt picks the host's version which is very wrong and ends up pointing the wrong Qt.

The Qt installation is split

In Craft, we split Qt into separate packages that are installed separately. This is the same split as in git, so qtbase contains QtCore and it's sister modules and qtdeclarative contains QtQml, QtQuickControls2, and so on. You can start to see where the problem is.

In cxx-qt, we use qmake to query where the headers are with the QT_INSTALL_HEADERS qmake built-in. Except that this only has one path(?), which is the one from qtbase. This means that it's currently impossible to build cxx-qt out of the box, as far as I'm aware.

CRAFT: user@5d0ff04fdbc2:~/CraftRoot$ ls /home/user/CraftRoot/build/libs/qt6/qtbase/image-MinSizeRel-6.8.0/include
QtConcurrent  QtDeviceDiscoverySupport  QtExamplesAssetDownloader  QtGui           QtNetwork  QtOpenGLWidgets  QtSql   QtWidgets
QtCore        QtExampleIcons            QtFbSupport                QtInputSupport  QtOpenGL   QtPrintSupport   QtTest  QtXml
CRAFT: user@5d0ff04fdbc2:~/CraftRoot$ ls /home/user/CraftRoot/build/libs/qt6/qtdeclarative/image-MinSizeRel-6.8.0/include
QtLabsAnimation        QtQmlAssetDownloader  QtQmlNetwork                    QtQuickControls2FluentWinUI3StyleImpl  QtQuickControls2UniversalStyleImpl  QtQuickTemplates2
QtLabsFolderListModel  QtQmlCompiler         QtQmlToolingSettings            QtQuickControls2Fusion                 QtQuickControlsTestUtils            QtQuickTest
QtLabsPlatform         QtQmlCore             QtQmlTypeRegistrar              QtQuickControls2FusionStyleImpl        QtQuickDialogs2                     QtQuickTestUtils
QtLabsQmlModels        QtQmlDebug            QtQmlWorkerScript               QtQuickControls2Imagine                QtQuickDialogs2QuickImpl            QtQuickVectorImage
QtLabsSettings         QtQmlDom              QtQmlXmlListModel               QtQuickControls2ImagineStyleImpl       QtQuickDialogs2Utils                QtQuickVectorImageGenerator
QtLabsSharedImage      QtQmlIntegration      QtQuick                         QtQuickControls2Impl                   QtQuickEffects                      QtQuickWidgets
QtLabsWavefrontMesh    QtQmlLocalStorage     QtQuickControls2                QtQuickControls2Material               QtQuickLayouts
QtPacketProtocol       QtQmlMeta             QtQuickControls2Basic           QtQuickControls2MaterialStyleImpl      QtQuickParticles
QtQml                  QtQmlModels           QtQuickControls2BasicStyleImpl  QtQuickControls2Universal              QtQuickShapes

(cxx-qt-build only includes /home/user/CraftRoot/build/libs/qt6/qtbase/image-MinSizeRel-6.8.0/include, so stuff like QQmlApplication can't build out of the box.)

In cxx-kde-frameworks, we have started using cmake-package-rs to use the existing CMake modules from KDE Frameworks, I wonder if that'll work here too? That way we can depend less on qmake too.

[ahayzen-kdab]

Hmm, I wonder how CMake is finding things in this case? And ideally it would be nice if a cargo-only build can continue to only depend on Qt/qmake and not CMake existing 🤔 But I wonder if this continues being an up hill battle, something to think about in the build system refactor.

[redstrate]

Hmm, I wonder how CMake is finding things in this case?

Because CMake modules work completely different. The modules themselves can declare where their include headers live (usually under the targets file. See Qt6QuickControls2Targets.cmake.) Craft installs the modules like how Qt normally installs them, under /home/user/CraftRoot/lib/cmake/<Qt module name> and then everything else shakes out.

And ideally it would be nice if a cargo-only build can continue to only depend on Qt/qmake and not CMake existing 🤔 But I wonder if this continues being an up hill battle, something to think about in the build system refactor.

It doesn't necessarily have to depend on CMake being available, we could have it as an optional thing. In most scenarios, qmake works fine. We just have a special case in KDE :) And as I suggested earlier, I hacked in cmake-package-rs support and got it to build farther.

[LeonMatthesKDAB]

Hm, as we abstract this via qt_build_utils, in principle it's okay with supporting both CMake and QMake "backend" essentially.
We should check how much effort it is to support though. As long as cmake_package does a reasonable job we could add it as a fallback/option.

[redstrate]

Hm, as we abstract this via qt_build_utils, in principle it's okay with supporting both CMake and QMake "backend" essentially. We should check how much effort it is to support though. As long as cmake_package does a reasonable job we could add it as a fallback/option.

Which I have started in #1156 :)