Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

stdenv: remove assumption of exactly two cross stages #251299

Closed
wants to merge 4 commits into from
Closed

stdenv: remove assumption of exactly two cross stages #251299

wants to merge 4 commits into from

Commits on Oct 22, 2023

  1. stdenv: pass actuallySplice explicitly 

    Previously, stdenv used `adjacentPackages==null` to signal that
`actuallySplice` should be `false`.  Let's pass it explicitly for
greater clarity.
    Adam Joseph committed Oct 22, 2023
    Configuration menu
    Copy the full SHA
    eda7de0 View commit details
    Browse the repository at this point in the history

  2. stdenv: remove selfBuild parameter 

    It's quite difficult to understand what this `selfBuild` parameter
is signaling, but it turns out to simply indicate which stages have
any kind of cross compilation (i.e. either build!=host or
host!=target).

Let's check that condition directly for greater clarity.
    Adam Joseph committed Oct 22, 2023
    Configuration menu
    Copy the full SHA
    7e6bbde View commit details
    Browse the repository at this point in the history

  3. stdenv: remove assumption that there are exactly two non-native stages 

    The native stdenv bootstrap (e.g. `pkgs/stdenv/linux/default.nix`)
is very elegantly structured as a sequence of arbitrarily-many
stages.  This makes it easy to refactor and modularize and reuse,
because if a stage gets too complicated we can just split it up into
two separate sequential stages.  We can also insert optional stages.

Unfortunately we can't do the same thing with cross-compiled
stdenvs, because `adjacentPackages` includes the hardwired
assumption that there are exactly two stages after the end of the
native bootstrap stage sequence:

  - The (build==host)!=target stage
  - The build!=(host==target) stage

This commit eliminates that assumption.  Instead of resolving things
like `pkgsBuildHost` to `prevStage`, we instead *search backwards*
for the most recent stage which creates packages on our
buildPlatform and for our hostPlatform.

This commit should not affect eval.

Note that `pkgsTargetTarget`, which becomes `targetPackages` still
has hardwired assumptions.  I think setting `pkgsTargetTarget` to
`nextStage` is just flat-out wrong for every stage except the "main"
stage (the `build!=(host==target)` stage), but I fear that there may
be code that relies on the particular way that it is wrong.  It
looks like `pkgsTargetTarget` and `targetPackages` exist exclusively
in order to provide access to the `postStage` hack; I intend to
submit a separate PR that `throw`s if it is used in any other way,
to see what breaks.

Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
    @roberth
    Adam Joseph and roberth committed Oct 22, 2023
    Configuration menu
    Copy the full SHA
    b4ca0a9 View commit details
    Browse the repository at this point in the history

  4. stdenv: cross: insert no-op stages 

    This commit inserts extra stages into the cross-compilation stdenv
bootstrap in order to prevent assumptions about the number of stages
from creeping back in (see previous commit).

If this commit is used without the previous commit, eval will fail
badly.  The no-op stages added by this commit serve as an example of
what wasn't possible before the PR which includes them.

Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
    @roberth
    Adam Joseph and roberth committed Oct 22, 2023
    Configuration menu
    Copy the full SHA
    232fdd8 View commit details
    Browse the repository at this point in the history