qt5: cross compile with a clean separation of build and host binaries #267311
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
eryngion
commented
Nov 13, 2023
eryngion
commented
Nov 13, 2023
| @@ -56,7 +52,7 @@ qmakePathHook() { | |||
| QMAKEPATH="${QMAKEPATH}${QMAKEPATH:+:}$1" | |||
| fi | |||
| } | |||
| envBuildHostHooks+=(qmakePathHook) | |||
| envHostTargetHooks+=(qmakePathHook) | |||
There was a problem hiding this comment.
Maybe qmakePathHook should be run for both types of packages? Not sure yet.
|
@amjoseph-nixpkgs @Artturin |
FliegendeWurst
added
the
6.topic: cross-compilation
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.
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.
… 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.
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.
It needs only qtdeclarative to build, not qtquickcontrols.
If you're a nativeBuildInput somewhere, you probably shouldn't propagate qtbase.
…s with qttools as a buildInput And don't propagate qtbase to avoid pulling in a second qtbase.dev in cross builds.
The sources in tarbals are identical, and hyphen from pkgs properly supports cross compilation.
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.
Not sure why it was done. This reverts commit 49e8d9d.
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?
Rely on callPackage whenever possible. And pass a spliced version of stdenv to fix cross compilaton for qtwebengine.
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.
Artturin
force-pushed
the
qt5-cross-with-a-clean-native-split
branch
from
a5ebde0
to
27353f1
Compare
|
Rebased. |
|
|
13 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
By default when cross compiling QT builds all binaries that are marked in their .pro files with
option(host_build)for the build platform instead of the host platform, and those binaries end up in the dev outputs (maybe not only there) of packages intended for the host platform. While there is some expectation of this situation in Nix [1], it prevents us from easily swapping natively and cross built dependencies, i.e. "lazy cross-compiling" and the host platform doesn't get the full set of binaries.Here I'm attempting to have only host-targeted binaries in the cross-compiled packages and somehow live with this new situation. Even if this approach fails, I have here a couple of fixes that can helpful elsewhere.
I'll direct this PR to staging when we will be done discussing it.
[1]
patchShebangsexpects that binaries in dev outputs will be run on the build platform, andpropagatedNativeBuildInputs, being implemented as an in-store dependency, essentially adds the same hard dependency on the platform where the package was built.Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)