From 11f5136005567dce5d92791b97192cf03edd4855 Mon Sep 17 00:00:00 2001 From: Matthew Bauer Date: Tue, 23 May 2017 22:04:11 -0500 Subject: [PATCH 1/2] 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 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. 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. From e9e9af4b5c10cb7712ae3cb9ee3154316feec660 Mon Sep 17 00:00:00 2001 From: Matthew Bauer Date: Wed, 24 May 2017 02:02:14 -0500 Subject: [PATCH 2/2] doc/cross-compilation: change cross to target thanks to @bjornfor for catching this --- doc/cross-compilation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/cross-compilation.xml b/doc/cross-compilation.xml index b66205dda91c..de1b9b80d300 100644 --- a/doc/cross-compilation.xml +++ b/doc/cross-compilation.xml @@ -30,7 +30,7 @@
Platform parameters - The three GNU Autoconf platforms, build, host, and cross, are historically the result of much confusion. + The three GNU Autoconf platforms, build, host, and target, are historically the result of much confusion. clears this up somewhat but there is more to be said. An important advice to get out the way is, unless you are packaging a compiler or other build tool, just worry about the build and host platforms. Dealing with just two platforms usually better matches people's preconceptions, and in this case is completely correct.