qt5: cross compile with a clean separation of build and host binaries #267311
Commits on May 28, 2024
-
-
Revert "nixos/no-x-libs: build qtbase without qt translation"
Not sure what was the problem here, but as of next commit qtbase successfully builds with `environment.noXlibs = true` and qttranslations. This reverts commit 2e14d8b.
-
Add to qtbase support for building a small bootstrap package. Move qmake and other tools from qtbase.dev to qtbase.qmake to avoid pulling in a second version of qtbase.dev in cross builds. Use hidden bootstrap packages for qtbase and qttools instead of overrideScope-based staging process to solve some spurious builds and infinite recursions. This commit by itself will allow to cross compile only qttranslations and qtbase.
-
qt5.qtbase: always build all packaged binaries for the hostPlatform
Also teach the setup hook, qmake and cmake scripts to search various build tools in PATH and use them for cross compilation. This will allow to cross compile packages that require only qtbase and qmake.
-
qt5.qtbase: support substituting a cross-built qtbase dependency with…
… a native-built one For this we need to dynamically detect cross compilation in qtbase-setup-hook.sh and in mkspecs, and stop unconditionally using binary lndir in propagatedNativeBuildInputs. For now qtbase substitution will work only in one (most used) direction, and in many cases will additionally require to manually add a buildHost version of qtbase.qmake to nativeBuildInputs of the package that depends on qtbase.
-
-
qt5: fix discovery of QT modules in cross builds
Without it qtwebchannel will fail to find some library includes, qtquickcontrols will refuse to build without properly failing the build: ``` Some of the required modules (qtHaveModule(quick)) are not available. Skipped. ``` And there are probably more problems, not always obvious.
-
qt5.qtwayland: fix cross compilation and dependencies
It needs only qtdeclarative to build, not qtquickcontrols.
-
qt5.qtdeclarative: fix cross for qtdeclarative and some of it's users
If you're a nativeBuildInput somewhere, you probably shouldn't propagate qtbase.
-
qt5.qttools: fix detection of lrelease and other tools in cross build…
…s with qttools as a buildInput And don't propagate qtbase to avoid pulling in a second qtbase.dev in cross builds.
-
-
qt5.qtwebkit: use hyphen from pkgs
The sources in tarbals are identical, and hyphen from pkgs properly supports cross compilation.
-
qt5.qtwebkit: add missing optional deps
It will use the bundled woff2 lib if we don't provide a system one. And "DWARF optimization and duplicate removal tool" is just nice to have, I guess.
-
Revert "qt5.qtwebchannel: omit "bin" output when cross compiling"
Not sure why it was done. This reverts commit 49e8d9d.
-
-
-
pyqtwebengine: update cross compilation support
I expect here that qtwebengine will propagate qtwebchannel and qtdeclarative and that qtdeclarative will propagate itself as a nativeBuildInput. But maybe we shouldn't rely on those propagations?
-
-
qt5.full: simplify package functions' definitions and calls
Rely on callPackage whenever possible. And pass a spliced version of stdenv to fix cross compilaton for qtwebengine.
-
qt5.qtbase: remove broken QMAKEMODULES code
It never worked and it's just an attempt to duplicate the logic from qmake (i.e. QMAKEPATH -> QMAKEMODULES translation) that qmake does all by itself.
-
