Merge pull request #22387 from Ericson2314/cross-3-platforms
cross stdenv: let build package's build deps resolve to native packages
This commit is contained in:
commit
f6ef6b56fe
@ -105,14 +105,15 @@
|
||||
This is the most important guiding principle behind cross-compilation with Nixpkgs, and will be called the <wordasword>sliding window principle</wordasword>.
|
||||
In this manner, given the 3 platforms for one package, we can determine the three platforms for all its transitive dependencies.
|
||||
</para>
|
||||
<para>
|
||||
Some examples will probably make this clearer.
|
||||
If a package is being built with a <literal>(build, host, target)</literal> platform triple of <literal>(foo, bar, bar)</literal>, then its build-time dependencies would have a triple of <literal>(foo, foo, bar)</literal>, and <emphasis>those packages'</emphasis> build-time dependencies would have triple of <literal>(foo, foo, foo)</literal>.
|
||||
In other words, it should take two "rounds" of following build-time dependency edges before one reaches a fixed point where, by the sliding window principle, the platform triple no longer changes.
|
||||
Indeed, this happens with cross compilation, where only rounds of native dependencies starting with the second necessarily coincide with native packages.
|
||||
</para>
|
||||
<note><para>
|
||||
The depending package's target platform is unconstrained by the sliding window principle, which makes sense in that one can in principle build cross compilers targeting arbitrary platforms.
|
||||
</para></note>
|
||||
<warning><para>
|
||||
From the above, one would surmise that if a package is being built with a <literal>(build, host, target)</literal> platform triple of <literal>(foo, bar, bar)</literal>, then its build-time dependencies would have a triple of <literal>(foo, foo, bar)</literal>, and <emphasis>those packages'</emphasis> build-time dependencies would have triple of <literal>(foo, foo, foo)</literal>.
|
||||
In other words, it should take two "rounds" of following build-time dependency edges before one reaches a fixed point where, by the sliding window principle, the platform triple no longer changes.
|
||||
Unfortunately, at the moment, we do <emphasis>not</emphasis> implement this correctly, and after only one round of following build-time dependencies is the fixed point reached, with target incorrectly kept different than the others.
|
||||
</para></warning>
|
||||
<para>
|
||||
How does this work in practice? Nixpkgs is now structured so that build-time dependencies are taken from from <varname>buildPackages</varname>, whereas run-time dependencies are taken from the top level attribute set.
|
||||
For example, <varname>buildPackages.gcc</varname> should be used at build time, while <varname>gcc</varname> should be used at run time.
|
||||
|
@ -18,8 +18,7 @@ in bootStages ++ [
|
||||
hostPlatform = localSystem;
|
||||
targetPlatform = crossSystem;
|
||||
inherit config overlays;
|
||||
# Should be false, but we're trying to preserve hashes for now
|
||||
selfBuild = true;
|
||||
selfBuild = false;
|
||||
# It's OK to change the built-time dependencies
|
||||
allowCustomOverrides = true;
|
||||
stdenv = vanillaPackages.stdenv // {
|
||||
|
Loading…
x
Reference in New Issue
Block a user