Details of Bootstrapping Stages and Platform Triples in Nixpkgs

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 bootstrapping stages leading up to the final stages are ignored in the previous paragraph. ::: If one looks at the 3 platform triples, one can see that they overlap such that one could put them together into a chain like: ``` (native, native, native, foreign, foreign) ``` If one imagines the saturating self references at the end being replaced with infinite stages, and then overlays those platform triples, one ends up with the infinite tuple: ``` (native..., native, native, native, foreign, foreign, foreign...) ``` One can then imagine any sequence of platforms such that there are bootstrap stages with their 3 platforms determined by "sliding a window" that is the 3 tuple through the sequence. This was the original model for bootstrapping. Without a target platform (assume a better world where all compilers are multi-target and all standard libraries are built in their own derivation), this is sufficient. Conversely if one wishes to cross compile "faster", with a "Canadian Cross" bootstrapping stage where `build != host != target`, more bootstrapping stages are needed since no sliding window provides the pesky `pkgsBuildTarget` package set since it skips the Canadian cross stage's "host".

This section elaborates on how the package sets (`pkgsBuildHost`, `pkgsBuildBuild`, `pkgsHostTarget`, `pkgsTargetTarget`) are defined within each bootstrapping stage. It also describes how these stages can be chained together to form a sequence of platforms, effectively creating an infinite tuple representing the bootstrapping process. The text mentions that this model is sufficient without a target platform. It further discusses how the need for "Canadian Cross" bootstrapping stages (where build, host, and target platforms differ) necessitates additional bootstrapping stages to provide the required `pkgsBuildTarget` package set.