KDAB
CXX-Qt does not work in split-Qt installations
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.
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 :thinking: But I wonder if this continues being an up hill battle, something to think about in the build system refactor.
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.
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.
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 :)