Skip to content

CXX-Qt does not work in split-Qt installations #1153

@redstrate

Description

@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.

Metadata

Metadata

Assignees

Labels

🔨 build systemIssues related to integrating CXX-Qt into CMake/Cargo🤔 discussionFeedback welcome🪲 bugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions