diff options
author | John Ericson <Ericson2314@yahoo.com> | 2017-02-05 17:41:31 -0500 |
---|---|---|
committer | GitHub <noreply@github.com> | 2017-02-05 17:41:31 -0500 |
commit | f6ef6b56fe6c659c51b0b4b866e393aa285389b8 (patch) | |
tree | 8e7d7d52cdc681bd2fad8fcdccf08e65973efc35 /doc | |
parent | 2c21f742b26e21c2a2bf8d960a364b8e29ad5ad9 (diff) | |
parent | 5eaea6cee01e9172ae65ccb6356861786a0f85cc (diff) | |
download | nixpkgs-f6ef6b56fe6c659c51b0b4b866e393aa285389b8.tar nixpkgs-f6ef6b56fe6c659c51b0b4b866e393aa285389b8.tar.gz nixpkgs-f6ef6b56fe6c659c51b0b4b866e393aa285389b8.tar.bz2 nixpkgs-f6ef6b56fe6c659c51b0b4b866e393aa285389b8.tar.lz nixpkgs-f6ef6b56fe6c659c51b0b4b866e393aa285389b8.tar.xz nixpkgs-f6ef6b56fe6c659c51b0b4b866e393aa285389b8.tar.zst nixpkgs-f6ef6b56fe6c659c51b0b4b866e393aa285389b8.zip |
Merge pull request #22387 from Ericson2314/cross-3-platforms
cross stdenv: let build package's build deps resolve to native packages
Diffstat (limited to 'doc')
-rw-r--r-- | doc/cross-compilation.xml | 11 |
1 files changed, 6 insertions, 5 deletions
diff --git a/doc/cross-compilation.xml b/doc/cross-compilation.xml index e93d1a98f7f..32cf198449b 100644 --- a/doc/cross-compilation.xml +++ b/doc/cross-compilation.xml @@ -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. |