From 11f5136005567dce5d92791b97192cf03edd4855 Mon Sep 17 00:00:00 2001 From: Matthew Bauer Date: Tue, 23 May 2017 22:04:11 -0500 Subject: [PATCH] doc/cross-compilation: cleanup some grammar These all should be uncontroversial changes. Just some awkward wording and double words, etc. --- doc/cross-compilation.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/cross-compilation.xml b/doc/cross-compilation.xml index 728616a9f26..b66205dda91 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. 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. - How does this work in practice? Nixpkgs is now structured so that build-time dependencies are taken from from buildPackages, 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 buildPackages, whereas run-time dependencies are taken from the top level attribute set. For example, buildPackages.gcc should be used at build time, while gcc should be used at run time. Now, for most of Nixpkgs's history, there was no buildPackages, 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 . + Instead, one can use the four attributes used for specifying dependencies as documented in . We "splice" together the run-time and build-time package sets with callPackage, and then mkDerivation 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 buildPackages needed.