1da4b5c99e
This will allow buliding bootstrap tools for platforms with
non-default libcs, like *-unknown-linux-musl.
This gets rid of limitedSupportSystems/systemsWithAnySupport. There
was no need to use systemsWithAnySupport for supportDarwin, because it
was always equivalent to supportedSystems for that purpose, and the
only other way it was used was for determining which platforms to
build the bootstrap tools for, so we might as well use a more explicit
parameter for that, and then we can change how it works without
affecting the rest of the Hydra jobs.
Not affecting the rest of the Hydra jobs is important, because if we
changed all jobs to use config triples, we'd end up renaming every
Hydra job. That might still be worth thinking about at some point,
but it's unnecessary at this point (and would be a lot of work).
I've checked by running
nix-eval-jobs --force-recurse pkgs/top-level/release.nix
that the actual bootstrap tools derivations are unaffected by this
change, and that the only other jobs that change are ones that depend
on the hash of all of Nixpkgs. Of the other jobset entrypoints that
end up importing pkgs/top-level/release.nix, none used the
limitedSupportedSystems parameter, so they should all be unaffected as
well.
|
||
|---|---|---|
| .. | ||
| default.nix | ||
| fixed-xnu-python3.patch | ||
| make-bootstrap-tools.nix | ||
| patch-bootstrap-tools-next.sh | ||
| portable-libsystem.sh | ||
| README.md | ||
| unpack-bootstrap-tools-aarch64.sh | ||
| unpack-bootstrap-tools.sh | ||
Darwin stdenv design goals
There are two more goals worth calling out explicitly:
- The standard environment should build successfully with sandboxing enabled on Darwin. It is
fine if a package requires a
sandboxProfileto build, but it should not be necessary to disable the sandbox to build the stdenv successfully; and - The output should depend weakly on the bootstrap tools. Historically, Darwin required updating
the bootstrap tools prior to updating the version of LLVM used in the standard environment.
By not depending on a specific version, the LLVM used on Darwin can be updated simply by
bumping the definition of llvmPackages in
all-packages.nix.
Updating the stdenv
There are effectively two steps when updating the standard environment:
- Update the definition of llvmPackages in
all-packages.nixfor Darwin to match the value of llvmPackages.latest inall-packages.nix. Timing-wise, this done currently using the spring release of LLVM and once llvmPackages.latest has been updated to match. If the LLVM project has announced a release schedule of patch updates, wait until those are in nixpkgs. Otherwise, the LLVM updates will have to go through staging instead of being merged into master; and - Fix the resulting breakage. Most things break due to additional warnings being turned into errors or additional strictness applied by LLVM. Fixes may come in the form of disabling those new warnings or by fixing the actual source (e.g., with a patch or update upstream). If the fix is trivial (e.g., adding a missing int to an implicit declaration), it is better to fix the problem instead of silencing the warning.