diff --git a/doc/languages-frameworks/android.section.md b/doc/languages-frameworks/android.section.md index f268c552566..9a5df2523a2 100644 --- a/doc/languages-frameworks/android.section.md +++ b/doc/languages-frameworks/android.section.md @@ -95,7 +95,7 @@ $ nix-build The Android SDK gets deployed with all desired plugin versions. -We can also deploy subsets of the Android SDK. For example, to only the the +We can also deploy subsets of the Android SDK. For example, to only the `platform-tools` package, you can evaluate the following expression: ```nix diff --git a/doc/languages-frameworks/rust.section.md b/doc/languages-frameworks/rust.section.md index 8b9aa5dc168..709a0d504cf 100644 --- a/doc/languages-frameworks/rust.section.md +++ b/doc/languages-frameworks/rust.section.md @@ -203,7 +203,7 @@ argument and returns a set that contains all attribute that should be overwritten. For more complicated cases, such as when parts of the crate's -derivation depend on the the crate's version, the `attrs` argument of +derivation depend on the crate's version, the `attrs` argument of the override above can be read, as in the following example, which patches the derivation: diff --git a/doc/stdenv/cross-compilation.xml b/doc/stdenv/cross-compilation.xml index 93fe9095ce2..5476c9a4893 100644 --- a/doc/stdenv/cross-compilation.xml +++ b/doc/stdenv/cross-compilation.xml @@ -348,12 +348,12 @@ nix-build '<nixpkgs>' --arg crossSystem '{ config = "<arch>-<os&g - In each stage, pkgsBuildHost refers the the previous stage, pkgsBuildBuild refers to the one before that, and 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 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 each instead. All the primary edges are implemented is in pkgs/stdenv/booter.nix, and secondarily aliases in pkgs/top-level/stage.nix. + In each stage, pkgsBuildHost refers to the previous stage, pkgsBuildBuild refers to the one before that, and 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 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 each instead. All the primary edges are implemented is in pkgs/stdenv/booter.nix, and secondarily aliases in pkgs/top-level/stage.nix. - Note the native stages are bootstrapped in legacy ways that predate the current cross implementation. This is why the the bootstrapping stages leading up to the final stages are ignored inthe previous paragraph. + Note the native stages are bootstrapped in legacy ways that predate the current cross implementation. This is why the bootstrapping stages leading up to the final stages are ignored inthe previous paragraph.