diff options
author | Matthew Bauer <mjbauer95@gmail.com> | 2017-05-23 22:04:11 -0500 |
---|---|---|
committer | Matthew Bauer <mjbauer95@gmail.com> | 2017-05-23 23:40:37 -0500 |
commit | 11f5136005567dce5d92791b97192cf03edd4855 (patch) | |
tree | a19f3a75a82913e94f831286ce8ef21228b76e26 /doc | |
parent | 9d5c28d22cf6573da2f75da2b9ec67f351c92f7d (diff) |
doc/cross-compilation: cleanup some grammar
These all should be uncontroversial changes. Just some awkward wording and
double words, etc.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/cross-compilation.xml | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/cross-compilation.xml b/doc/cross-compilation.xml index 728616a9f263..b66205dda91c 100644 --- a/doc/cross-compilation.xml +++ b/doc/cross-compilation.xml @@ -62,8 +62,8 @@ The "target platform" is black sheep. The other two intrinsically apply to all compiled software—or any build process with a notion of "build-time" followed by "run-time". The target platform only applies to programming tools, and even then only is a good for for some of them. - Briefly, GCC, Binutils, GHC, and certain other tools are written in such a way such that a single build can only compiler code for a single platform. - Thus, when building them, one must think ahead about what platforms they wish to use the tool to produce machine code for, and build binaries for each. + Briefly, GCC, Binutils, GHC, and certain other tools are written in such a way such that a single build can only compile code for a single platform. + Thus, when building them, one must think ahead about which platforms they wish to use the tool to produce machine code for, and build binaries for each. </para> <para> There is no fundamental need to think about the target ahead of time like this. @@ -158,10 +158,10 @@ 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> <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. + 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 <link linkend="ssec-stdenv-attributes" />. + Instead, one can use the four attributes used for specifying dependencies as documented in <xref linkend="ssec-stdenv-attributes"/>. 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. |