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:
John Ericson 2017-01-15 17:45:04 -05:00
parent a1a798f017
commit 4c17cd555f

View File

@ -83,6 +83,22 @@ in let
boot = import ../stdenv/booter.nix { inherit lib allPackages; };
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; };
inherit lib crossSystem config overlays;
};