cross stdenv: let build package's build deps resolve to native packages

This fixes the "sliding window" principle:
  0. Run packages:       build = native;  host = foreign; target = foreign;
  1. Build packages:     build = native;  host = native;  target = foreign;
  2. Vanilla packages:   build = native;  host = native;  target = native;
  3. Vanilla packages:   build = native;  host = native;  target = native;
  n+3. ...

Each stage's build dependencies are resolved against the previous stage,
and the "foreigns" are shifted accordingly. Vanilla packages alone are
built against themsevles, since there are no more "foreign"s to shift away.

Before, build packages' build dependencies were resolved against
themselves:
  0. Run packages:       build = native;  host = foreign; target = foreign;
  1. Build packages:     build = native;  host = native;  target = foreign;
  2. Build packages:     build = native;  host = native;  target = foreign;
  n+2. ...

This is wrong because that principle is violated by the target
platform staying foreign.

This will change the hashes of many build packages and run packages, but
that is OK. This is an unavoidable cost of fixing cross compiling.

The cross compilation docs have been updated to reflect this fix.

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.