nixpkgs/pkgs/stdenv/custom/default.nix

{ lib
, localSystem, crossSystem, config, overlays, crossOverlays ? []
}:

assert crossSystem == localSystem;

let
  bootStages = import ../. {
    inherit lib localSystem crossSystem overlays;
    # Remove config.replaceStdenv to ensure termination.
    config = builtins.removeAttrs config [ "replaceStdenv" ];
  };

in bootStages ++ [

  # Additional stage, built using custom stdenv
  (vanillaPackages: {
    inherit config overlays;
    stdenv =
      assert vanillaPackages.hostPlatform == localSystem;
      assert vanillaPackages.targetPlatform == localSystem;
      config.replaceStdenv { pkgs = vanillaPackages; };
  })

]
top-level: Normalize stdenv booting Introduce new abstraction, `stdenv/booter.nix` for composing bootstraping stages, and use it everywhere for consistency. See that file for more doc. Stdenvs besides Linux and Darwin are completely refactored to utilize this. Those two, due to their size and complexity, are minimally edited for easier reviewing. No hashes should be changed. 2016-12-16 13:22:02 +00:00			`{ lib`
stdenv: allow custom stdenv to take crossOverlays 2019-01-08 02:39:15 +00:00			`, localSystem, crossSystem, config, overlays, crossOverlays ? []`
top-level: Close over fewer arguments for stdenv stages This makes the flow of data easier to understand. There's little downside because the args in question are already inspected by the stdenvs. cross-compiling in particular is simpler because we don't need to worry about overriding the config closed over by `allPackages`. 2016-11-27 20:37:45 +00:00			`}:`
top-level: Make config-overriden stdenv bootstrap more normally 2016-04-27 16:09:27 +00:00
stdenv: implement crossOverlays crossOverlays only apply to the packages being built, not the build packages. It is useful when you don’t care what is used to build your packages, just what is being built. The idea relies heavily on the cross compiling infrastructure. Using this implies that we need to create a cross stdenv. 2018-12-05 03:06:46 +00:00			`assert crossSystem == localSystem;`
top-level: turn the screw - Non-cross stdenvs are honest and assert that `crossSystem` is null - `crossSystem` is a mandatory argument to top-level/stage.nix, just like `system` and `platform` - Broken default arguments on stdenvs for testing are gone. - All stdenvs (but little-used stdenvNix) take the same arguments for easy testing. 2016-11-30 23:51:13 +00:00
top-level: Normalize stdenv booting Introduce new abstraction, `stdenv/booter.nix` for composing bootstraping stages, and use it everywhere for consistency. See that file for more doc. Stdenvs besides Linux and Darwin are completely refactored to utilize this. Those two, due to their size and complexity, are minimally edited for easier reviewing. No hashes should be changed. 2016-12-16 13:22:02 +00:00			`let`
			`bootStages = import ../. {`
top-level: Lay the groundwork for `{build,host,target}Platform` The long term goal is a big replace: { inherit system platform; } => buildPlatform crossSystem => hostPlatform stdenv.cross => targetPlatform And additionally making sure each is defined even when not cross compiling. This commit refactors the bootstrapping code along that vision, but leaves the old identifiers with their null semantics in place so packages can be modernized incrementally. 2016-12-24 18:55:11 +00:00			`inherit lib localSystem crossSystem overlays;`
top-level: Make config-overriden stdenv bootstrap more normally 2016-04-27 16:09:27 +00:00			`# Remove config.replaceStdenv to ensure termination.`
			`config = builtins.removeAttrs config [ "replaceStdenv" ];`
top-level: Close over fewer arguments for stdenv stages This makes the flow of data easier to understand. There's little downside because the args in question are already inspected by the stdenvs. cross-compiling in particular is simpler because we don't need to worry about overriding the config closed over by `allPackages`. 2016-11-27 20:37:45 +00:00			`};`
top-level: Make config-overriden stdenv bootstrap more normally 2016-04-27 16:09:27 +00:00
top-level: Normalize stdenv booting Introduce new abstraction, `stdenv/booter.nix` for composing bootstraping stages, and use it everywhere for consistency. See that file for more doc. Stdenvs besides Linux and Darwin are completely refactored to utilize this. Those two, due to their size and complexity, are minimally edited for easier reviewing. No hashes should be changed. 2016-12-16 13:22:02 +00:00			`in bootStages ++ [`

			`# Additional stage, built using custom stdenv`
			`(vanillaPackages: {`
top-level: Lay the groundwork for `{build,host,target}Platform` The long term goal is a big replace: { inherit system platform; } => buildPlatform crossSystem => hostPlatform stdenv.cross => targetPlatform And additionally making sure each is defined even when not cross compiling. This commit refactors the bootstrapping code along that vision, but leaves the old identifiers with their null semantics in place so packages can be modernized incrementally. 2016-12-24 18:55:11 +00:00			`inherit config overlays;`
top-level: {build,host,target}Platform are defined in the stdenv instead See #27069 for a discussion of this 2017-07-06 01:47:48 +00:00			`stdenv =`
			`assert vanillaPackages.hostPlatform == localSystem;`
			`assert vanillaPackages.targetPlatform == localSystem;`
			`config.replaceStdenv { pkgs = vanillaPackages; };`
top-level: Normalize stdenv booting Introduce new abstraction, `stdenv/booter.nix` for composing bootstraping stages, and use it everywhere for consistency. See that file for more doc. Stdenvs besides Linux and Darwin are completely refactored to utilize this. Those two, due to their size and complexity, are minimally edited for easier reviewing. No hashes should be changed. 2016-12-16 13:22:02 +00:00			`})`
top-level: Make config-overriden stdenv bootstrap more normally 2016-04-27 16:09:27 +00:00
top-level: Normalize stdenv booting Introduce new abstraction, `stdenv/booter.nix` for composing bootstraping stages, and use it everywhere for consistency. See that file for more doc. Stdenvs besides Linux and Darwin are completely refactored to utilize this. Those two, due to their size and complexity, are minimally edited for easier reviewing. No hashes should be changed. 2016-12-16 13:22:02 +00:00			`]`