diff options
author | John Ericson <Ericson2314@Yahoo.com> | 2017-06-02 12:22:36 -0400 |
---|---|---|
committer | John Ericson <John.Ericson@Obsidian.Systems> | 2017-12-30 22:35:59 -0500 |
commit | 7ffc4e1b2ff051ff5c012f411ac824b89a160dd6 (patch) | |
tree | 49ed51f82f8300657c9b1f5adda22a1b60504c3a /doc/cross-compilation.xml | |
parent | e9a369b2c6f9a6c8d81ae3a0ca35bf12fd239f38 (diff) |
doc: Add "Specifying Dependencies" section to the stdenv chapter
This accounts for all the new dependencies and propagation logic changes I'm about to add. Fixes #1915---with this change I think the distinction is finally clear enough.
Diffstat (limited to 'doc/cross-compilation.xml')
-rw-r--r-- | doc/cross-compilation.xml | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/doc/cross-compilation.xml b/doc/cross-compilation.xml index 4b35b72feae03..f1194720cfd5f 100644 --- a/doc/cross-compilation.xml +++ b/doc/cross-compilation.xml @@ -187,7 +187,7 @@ How does this work in practice? Nixpkgs is now structured so that build-time dependencies are taken 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. Now, for most of Nixpkgs's history, there was no <varname>buildPackages</varname>, and most packages have not been refactored to use it explicitly. - Instead, one can use the four attributes used for specifying dependencies as documented in <xref linkend="ssec-stdenv-attributes"/>. + Instead, one can use the six (<emphasis>gasp</emphasis>) attributes used for specifying dependencies as documented in <xref linkend="ssec-stdenv-dependencies"/>. We "splice" together the run-time and build-time package sets with <varname>callPackage</varname>, and then <varname>mkDerivation</varname> for each of four attributes pulls the right derivation out. This splicing can be skipped when not cross compiling as the package sets are the same, but is a bit slow for cross compiling. Because of this, a best-of-both-worlds solution is in the works with no splicing or explicit access of <varname>buildPackages</varname> needed. |