top-level: Document the {local,cross}System, contrasting with
*Platform`
This is an implementation detail of how the bootstrapping chain is chosen, and thus need not be in the manual.
This commit is contained in:
parent
a1a798f017
commit
4c17cd555f
@ -83,6 +83,22 @@ in let
|
|||||||
boot = import ../stdenv/booter.nix { inherit lib allPackages; };
|
boot = import ../stdenv/booter.nix { inherit lib allPackages; };
|
||||||
|
|
||||||
stages = stdenvStages {
|
stages = stdenvStages {
|
||||||
|
# One would think that `localSystem` and `crossSystem` overlap horribly with
|
||||||
|
# the three `*Platforms` (`buildPlatform`, `hostPlatform,` and
|
||||||
|
# `targetPlatform`; see `stage.nix` or the manual). Actually, those
|
||||||
|
# identifiers I, @Ericson2314, purposefully not used here to draw a subtle
|
||||||
|
# but important distinction:
|
||||||
|
#
|
||||||
|
# While the granularity of having 3 platforms is necessary to properly
|
||||||
|
# *build* packages, it is overkill for specifying the user's *intent* when
|
||||||
|
# making a build plan or package set. A simple "build vs deploy" dichotomy
|
||||||
|
# is adequate: the "sliding window" principle described in the manual shows
|
||||||
|
# how to interpolate between the these two "end points" to get the 3
|
||||||
|
# platform triple for each bootstrapping stage.
|
||||||
|
#
|
||||||
|
# Also, less philosophically but quite practically, `crossSystem` should be
|
||||||
|
# null when one doesn't want to cross-compile, while the `*Platform`s are
|
||||||
|
# always non-null. `localSystem` is always non-null.
|
||||||
localSystem = { inherit system platform; };
|
localSystem = { inherit system platform; };
|
||||||
inherit lib crossSystem config overlays;
|
inherit lib crossSystem config overlays;
|
||||||
};
|
};
|
||||||
|
Loading…
x
Reference in New Issue
Block a user