From 8ba4db0f11f7d1268b34c725f925c99be240b817 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Mon, 25 Mar 2019 17:50:13 -0400 Subject: [PATCH] manual: Fix typos Thanks @matthewbauer! Co-Authored-By: Ericson2314 --- doc/cross-compilation.xml | 34 +++++++++++++++++----------------- doc/stdenv.xml | 2 +- 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/doc/cross-compilation.xml b/doc/cross-compilation.xml index d97f12f25661..b7844da195d7 100644 --- a/doc/cross-compilation.xml +++ b/doc/cross-compilation.xml @@ -259,8 +259,8 @@ machine-code-producing tools, we're done. And indeed buildInputs and nativeBuildInputs have covered these simpler build-time and run-time (respectively) changes - for many years. But if the depedency does produce machine code, we might - need to worry about it's target platform too. In principle, that target + for many years. But if the dependency does produce machine code, we might + need to worry about its target platform too. In principle, that target platform might be any of the depending package's build, host, or target platforms, but we prohibit dependencies from a "later" platform to an earlier platform to limit confusion because we've never seen a legitimate @@ -270,7 +270,7 @@ Finally, if the depending package is a compiler or other machine-code-producing tool, it might need dependencies that run at "emit - time". This is for compilers that (regrettably) insist on being in built + time". This is for compilers that (regrettably) insist on being built together with their source langauges' standard libraries. Assuming build != host != target, a run-time dependency of the standard library cannot be run at the compiler's build time or run time, but only at the run time of code @@ -485,9 +485,9 @@ nix-build <nixpkgs> --arg crossSystem '{ config = "<arch>-<os> are specified as lists of derivations given to mkDerivation, as - documented in . In short, the + documented in . In short, each list of dependencies for "host → target" of "foo → bar" is called - depsFooBar, with the exceptions for backwards + depsFooBar, with exceptions for backwards compatibility that depsBuildHost is instead called nativeBuildInputs and depsHostTarget is instead called buildInputs. Nixpkgs is now structured @@ -501,13 +501,13 @@ nix-build <nixpkgs> --arg crossSystem '{ config = "<arch>-<os> - Now, for most of Nixpkgs's history, there was no + Now, for most of Nixpkgs's history, there were no pkgsFooBar attributes, and most packages have not been refactored to use it explicitly. Prior to those, there were just buildPackages, pkgs, and targetPackages. Those are now redefined as aliases to pkgsBuildHost, pkgsHostTarget, and - pkgsTargetTarget. It is fine, indeed if anything + pkgsTargetTarget. It is acceptable, even recommended, to use them for libraries to show that the host platform is irrelevant. @@ -523,12 +523,12 @@ nix-build <nixpkgs> --arg crossSystem '{ config = "<arch>-<os> their dependencies into the multiple lists described above. And indeed, asking that users both sort their dependencies, and take them from the right attribute set, is both too onerous and redundant, - so the recommend approach (for now) is to continue just categorizing by + so the recommended approach (for now) is to continue just categorizing by list and not using an explicit package set. - No make this work, we "splice" together the six + To make this work, we "splice" together the six pkgsFooBar package sets and have callPackage actually take its arguments from that. This is currently implemented in pkgs/top-level/splice.nix. @@ -550,7 +550,7 @@ nix-build <nixpkgs> --arg crossSystem '{ config = "<arch>-<os> pkgs/top-level/stage.nix "ties the knot" (creates the fixed point) of each stage. The package sets are defined per-stage however, so they can be thought of as edges between stages (the nodes) in a graph. - Compositions like pkgsBuildTarget.TargetPackages can be + Compositions like pkgsBuildTarget.targetPackages can be thought of as paths to this graph. @@ -581,12 +581,12 @@ nix-build <nixpkgs> --arg crossSystem '{ config = "<arch>-<os> pkgsHostTarget refers to the current one, and pkgsTargetTarget refers to the next one. When there is no previous or next stage, they instead refer to the current stage. Note - how all the invariants about the mapping between dependency and depending + how all the invariants regarding the mapping between dependency and depending packages' build host and target platforms are preserved. pkgsBuildTarget and pkgsHostHost are more complex in that the stage fitting the requirements isn't always a fixed chain of "prevs" and "nexts" away (modulo the "saturating" - self-references at the ends). We just special case instead. All the primary + self-references at the ends). We just special case each instead. All the primary edges are implemented is in pkgs/stdenv/booter.nix, and secondarily aliases in pkgs/top-level/stage.nix. @@ -642,10 +642,10 @@ nix-build <nixpkgs> --arg crossSystem '{ config = "<arch>-<os> Second, it is because this is a frequent source of hard-to-follow - "infinite recursions" / cycles. When only packages sets that don't mention - target are used, the package set forms a directly acyclic graph. This - means that all cycles that exist are confirmed to one stage. This means - they are a lot smaller, so easier to follow in the code or a backtrace. It + "infinite recursions" / cycles. When only package sets that don't mention + target are used, the package set forms a directed acyclic graph. This + means that all cycles that exist are confined to one stage. This means + they are a lot smaller, and easier to follow in the code or a backtrace. It also means they are present in native and cross builds alike, and so more likely to be caught by CI and other users. @@ -653,7 +653,7 @@ nix-build <nixpkgs> --arg crossSystem '{ config = "<arch>-<os> Thirdly, it is because everything target-mentioning only exists to accommodate compilers with lousy build systems that insist on the compiler itself and standard library being built together. Of course that is bad - because bigger derivation means longer rebuilds. It is also subpar because + because bigger derivations means longer rebuilds. It is also problematic because it tends to make the standard libraries less like other libraries than they could be, complicating code and build systems alike. Because of the other problems, and because of these innate disadvantages, compilers ought diff --git a/doc/stdenv.xml b/doc/stdenv.xml index 85efbc1dd9dd..74f815fc1d79 100644 --- a/doc/stdenv.xml +++ b/doc/stdenv.xml @@ -224,7 +224,7 @@ genericBuild the dependency is needed at run-time or build-time, a concept that makes perfect sense outside of cross compilation. By default, the run-time/build-time distinction is just a hint for mental clarity, but with - strictDeps set it is somewhat enforced even in the native + strictDeps set it is mostly enforced even in the native case.