Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
redstrate opened this issue Dec 30, 2024 · 4 comments · May be fixed by #1156
Open

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

redstrate opened this issue Dec 30, 2024 · 4 comments · May be fixed by #1156
Assignees
@redstrate
Labels
🪲 bug Something isn't working 🔨 build system Issues related to integrating CXX-Qt into CMake/Cargo 🤔 discussion Feedback welcome

Comments

@redstrate
Copy link
Contributor

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.
@redstrate redstrate added 🪲 bug Something isn't working 🤔 discussion Feedback welcome labels Dec 30, 2024
@redstrate redstrate self-assigned this Dec 30, 2024
@redstrate redstrate added the 🔨 build system Issues related to integrating CXX-Qt into CMake/Cargo label Dec 30, 2024
@ahayzen-kdab
Copy link
Collaborator

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
Copy link
Contributor Author

redstrate commented Jan 10, 2025 •
edited
Loading

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.

@redstrate redstrate mentioned this issue Jan 10, 2025
Draft
@LeonMatthesKDAB
Copy link
Collaborator

LeonMatthesKDAB commented Jan 14, 2025 •
edited
Loading

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 added a commit to redstrate/cxx-qt that referenced this issue Jan 14, 2025
@redstrate
qt-build-utils: Add an option to use CMake instead of QMake
0fb6d0b 
This is needed for scenarios where the CMake packaging for Qt is better
than what QMake can handle, e.g. split Qt installations where the
modules live in different directories.

A new optional feature is added to cxx-qt-build to prefer CMake for most
operations related to linking/including Qt modules. QMake is still the
default.

Fixes KDAB#1153.
@redstrate redstrate linked a pull request Jan 14, 2025 that will close this issue
Open
@redstrate
Copy link
Contributor Author

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 :)

redstrate added a commit to redstrate/cxx-qt that referenced this issue Jan 15, 2025
@redstrate
qt-build-utils: Add an option to use CMake instead of QMake
bd7a8bd 
This is needed for scenarios where the CMake packaging for Qt is better
than what QMake can handle, e.g. split Qt installations where the
modules live in different directories.

A new optional feature is added to cxx-qt-build to prefer CMake for most
operations related to linking/including Qt modules. QMake is still the
default.

Fixes KDAB#1153.
redstrate added a commit to redstrate/cxx-qt that referenced this issue Jan 15, 2025
@redstrate
qt-build-utils: Add an option to use CMake instead of QMake
9f7238c 
This is needed for scenarios where the CMake packaging for Qt is better
than what QMake can handle, e.g. split Qt installations where the
modules live in different directories.

A new optional feature is added to cxx-qt-build to prefer CMake for most
operations related to linking/including Qt modules. QMake is still the
default.

Fixes KDAB#1153.
redstrate added a commit to redstrate/cxx-qt that referenced this issue Jan 15, 2025
@redstrate
qt-build-utils: Add an option to use CMake instead of QMake
66c1972 
This is needed for scenarios where the CMake packaging for Qt is better
than what QMake can handle, e.g. split Qt installations where the
modules live in different directories.

A new optional feature is added to cxx-qt-build to prefer CMake for most
operations related to linking/including Qt modules. QMake is still the
default.

Fixes KDAB#1153.
redstrate added a commit to redstrate/cxx-qt that referenced this issue Jan 15, 2025
@redstrate
qt-build-utils: Add an option to use CMake instead of QMake
1d29d33 
This is needed for scenarios where the CMake packaging for Qt is better
than what QMake can handle, e.g. split Qt installations where the
modules live in different directories.

A new optional feature is added to cxx-qt-build to prefer CMake for most
operations related to linking/including Qt modules. QMake is still the
default.

Fixes KDAB#1153.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@redstrate redstrate

Labels
🪲 bug Something isn't working 🔨 build system Issues related to integrating CXX-Qt into CMake/Cargo 🤔 discussion Feedback welcome
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

qt-build-utils: Add an option to use CMake instead of QMake redstrate/cxx-qt
3 participants
@redstrate @LeonMatthesKDAB @ahayzen-kdab