nixpkgs/pkgs/stdenv/darwin/default.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2499 lines
65 KiB
Nix
Raw Normal View History

darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# This file contains the standard build environment for Darwin. It is based on LLVM and is patterned
# after the Linux stdenv. It shares similar goals to the Linux standard environment in that the
# resulting environment should be built purely and not contain any references to it.
#
# For more on the design of the stdenv and updating it, see `README.md`.
#
# See also the top comments of the Linux stdenv `../linux/default.nix` for a good overview of
# the bootstrap process and working with it.
{
lib,
localSystem,
crossSystem,
config,
overlays,
crossOverlays ? [ ],
2021-06-02 04:25:56 +00:00
# Allow passing in bootstrap files directly so we can test the stdenv bootstrap process when changing the bootstrap tools
bootstrapFiles ?
if localSystem.isAarch64 then
import ./bootstrap-files/aarch64-apple-darwin.nix
else
import ./bootstrap-files/x86_64-apple-darwin.nix,
}:
assert crossSystem == localSystem;
let
inherit (localSystem) system;
useAppleSDKLibs = lib.versionAtLeast localSystem.darwinSdkVersion "11";
2020-11-19 08:28:20 +00:00
commonImpureHostDeps = [
"/bin/sh"
"/usr/lib/libSystem.B.dylib"
"/usr/lib/system/libunc.dylib" # This dependency is "hidden", so our scanning code doesn't pick it up
];
2020-11-19 08:28:20 +00:00
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
isFromNixpkgs = pkg: !(isFromBootstrapFiles pkg);
isFromBootstrapFiles = pkg: pkg.passthru.isFromBootstrapFiles or false;
isBuiltByNixpkgsCompiler = pkg: isFromNixpkgs pkg && isFromNixpkgs pkg.stdenv.cc.cc;
isBuiltByBootstrapFilesCompiler = pkg: isFromNixpkgs pkg && isFromBootstrapFiles pkg.stdenv.cc.cc;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
commonPreHook = ''
export NIX_ENFORCE_NO_NATIVE=''${NIX_ENFORCE_NO_NATIVE-1}
export NIX_ENFORCE_PURITY=''${NIX_ENFORCE_PURITY-1}
export NIX_IGNORE_LD_THROUGH_GCC=1
unset SDKROOT
'';
bootstrapTools =
derivation (
{
inherit system;
name = "bootstrap-tools";
builder = "${bootstrapFiles.unpack}/bin/bash";
args = [
"${bootstrapFiles.unpack}/bootstrap-tools-unpack.sh"
bootstrapFiles.bootstrapTools
];
PATH = lib.makeBinPath [
(placeholder "out")
bootstrapFiles.unpack
];
__impureHostDeps = commonImpureHostDeps;
}
// lib.optionalAttrs config.contentAddressedByDefault {
__contentAddressed = true;
outputHashAlgo = "sha256";
outputHashMode = "recursive";
}
)
// {
passthru.isFromBootstrapFiles = true;
};
stageFun =
prevStage:
{
name,
overrides ? (self: super: { }),
extraNativeBuildInputs ? [ ],
extraPreHook ? "",
}:
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
let
cc =
if prevStage.llvmPackages.clang-unwrapped == null then
null
else
lib.makeOverridable (import ../../build-support/cc-wrapper) {
name = "${name}-clang-wrapper";
nativeTools = false;
nativeLibc = false;
expand-response-params = lib.optionalString (
prevStage.stdenv.hasCC or false && prevStage.stdenv.cc != "/dev/null"
) prevStage.expand-response-params;
extraPackages = [ prevStage.llvmPackages.compiler-rt ];
extraBuildCommands =
let
inherit (prevStage.llvmPackages) clang-unwrapped compiler-rt release_version;
in
''
function clangResourceRootIncludePath() {
clangLib="$1/lib/clang"
if (( $(ls "$clangLib" | wc -l) > 1 )); then
echo "Multiple LLVM versions were found at "$clangLib", but there must only be one used when building the stdenv." >&2
exit 1
fi
echo "$clangLib/$(ls -1 "$clangLib")/include"
}
rsrc="$out/resource-root"
mkdir "$rsrc"
ln -s "$(clangResourceRootIncludePath "${clang-unwrapped.lib}")" "$rsrc"
ln -s "${compiler-rt.out}/lib" "$rsrc/lib"
ln -s "${compiler-rt.out}/share" "$rsrc/share"
echo "-resource-dir=$rsrc" >> $out/nix-support/cc-cflags
'';
cc = prevStage.llvmPackages.clang-unwrapped;
bintools = prevStage.darwin.binutils;
isClang = true;
libc = prevStage.darwin.Libsystem;
inherit (prevStage.llvmPackages) libcxx;
2020-11-19 08:28:20 +00:00
inherit lib;
inherit (prevStage) coreutils gnugrep;
2020-11-19 08:28:20 +00:00
stdenvNoCC = prevStage.ccWrapperStdenv;
runtimeShell = prevStage.ccWrapperStdenv.shell;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
bash = prevStage.bash or bootstrapTools;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
thisStdenv = import ../generic {
name = "${name}-stdenv-darwin";
buildPlatform = localSystem;
hostPlatform = localSystem;
targetPlatform = localSystem;
inherit config;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
extraBuildInputs = [ prevStage.darwin.CF ];
extraNativeBuildInputs = extraNativeBuildInputs ++ [ prevStage.darwin.apple_sdk.sdkRoot ];
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
preHook =
lib.optionalString (!isBuiltByNixpkgsCompiler bash) ''
# Don't patch #!/interpreter because it leads to retained
# dependencies on the bootstrapTools in the final stdenv.
dontPatchShebangs=1
''
+ ''
${commonPreHook}
${extraPreHook}
''
+ lib.optionalString (prevStage.darwin ? locale) ''
export PATH_LOCALE=${prevStage.darwin.locale}/share/locale
'';
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
shell = bash + "/bin/bash";
initialPath = [
bash
bootstrapTools
];
fetchurlBoot = import ../../build-support/fetchurl {
inherit lib;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
stdenvNoCC = prevStage.ccWrapperStdenv or thisStdenv;
curl = bootstrapTools;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
inherit cc;
# The stdenvs themselves don't use mkDerivation, so I need to specify this here
__stdenvImpureHostDeps = commonImpureHostDeps;
__extraImpureHostDeps = commonImpureHostDeps;
# Using the bootstrap tools curl for fetchers allows the stdenv bootstrap to avoid
# having a dependency on curl, allowing curl to be updated without triggering a
# new stdenv bootstrap on Darwin.
overrides =
self: super:
(overrides self super)
// {
fetchurl = thisStdenv.fetchurlBoot;
fetchpatch = super.fetchpatch.override { inherit (self) fetchurl; };
fetchzip = super.fetchzip.override { inherit (self) fetchurl; };
};
};
2021-06-02 04:25:56 +00:00
in
{
inherit config overlays;
stdenv = thisStdenv;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
in
assert bootstrapTools.passthru.isFromBootstrapFiles or false; # sanity check
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
[
(
{ }:
{
__raw = true;
cctools = true;
ld64 = true;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
coreutils = null;
gnugrep = null;
pbzx = null;
cpio = null;
darwin = {
apple_sdk.sdkRoot = null;
binutils = null;
binutils-unwrapped = null;
print-reexports = null;
rewrite-tbd = null;
sigtool = null;
CF = null;
Libsystem = null;
};
llvmPackages = {
clang-unwrapped = null;
libllvm = null;
libcxx = null;
compiler-rt = null;
};
}
)
# Create a stage with the bootstrap tools. This will be used to build the subsequent stages and
# build up the standard environment.
#
# Note: Each stage depends only on the the packages in `prevStage`. If a package is not to be
# rebuilt, it should be passed through by inheriting it.
(
prevStage:
stageFun prevStage {
name = "bootstrap-stage0";
2020-11-19 08:28:20 +00:00
overrides = self: super: {
# We thread stage0's stdenv through under this name so downstream stages
# can use it for wrapping gcc too. This way, downstream stages don't need
# to refer to this stage directly, which violates the principle that each
# stage should only access the stage that came before it.
ccWrapperStdenv = self.stdenv;
bash = bootstrapTools // {
shellPath = "/bin/bash";
};
2020-11-19 08:28:20 +00:00
coreutils = bootstrapTools;
cpio = bootstrapTools;
gnugrep = bootstrapTools;
pbzx = bootstrapTools;
cctools = super.stdenv.mkDerivation {
pname = "bootstrap-stage0-cctools";
version = "boot";
buildCommand = ''
declare -a cctools=(
ar
bitcode_strip
check_dylib
checksyms
cmpdylib
codesign_allocate
ctf_insert
depinfo
diagtest
gas
gprof
install_name_tool
libtool
lipo
mtoc
mtor
nm
nmedit
otool
pagestuff
ranlib
redo_prebinding
seg_addr_table
seg_hack
segedit
size
strings
strip
vtool
)
mkdir -p "$out/bin"
for tool in "''${cctools[@]}"; do
toolsrc="${bootstrapTools}/bin/$tool"
if [ -e "$toolsrc" ]; then
ln -s "$toolsrc" "$out/bin"
fi
done
# Copy only the required headers to avoid accidentally linking headers that belong to other packages,
# which can cause problems when building Libsystem in the source-based SDK.
declare -a machohdrs=(
arch.h
fat.h
fixup-chains.h
getsect.h
ldsyms.h
loader.h
nlist.h
ranlib.h
reloc.h
stab.h
swap.h
arm
arm64
hppa
i386
i860
m68k
m88k
ppc
sparc
x86_64
)
mkdir -p "$out/include/mach-o"
for header in "''${machohdrs[@]}"; do
machosrc="${bootstrapTools}/include-Libsystem/mach-o/$header"
if [ -e "$machosrc" ]; then
cp -r "$machosrc" "$out/include/mach-o/$header"
fi
done
'';
2020-11-19 08:28:20 +00:00
passthru = {
isFromBootstrapFiles = true;
targetPrefix = "";
};
};
ld64 = bootstrapTools // {
targetPrefix = "";
version = "boot";
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
};
2020-11-19 08:28:20 +00:00
darwin = super.darwin.overrideScope (
selfDarwin: superDarwin:
{
# Prevent CF from being propagated to the initial stdenv. Packages that require it
# will have to manually add it to their build inputs.
CF = null;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
binutils = super.wrapBintoolsWith {
name = "bootstrap-stage0-binutils-wrapper";
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
nativeTools = false;
nativeLibc = false;
expand-response-params = "";
libc = selfDarwin.Libsystem;
inherit lib;
inherit (self) stdenvNoCC coreutils gnugrep;
runtimeShell = self.stdenvNoCC.shell;
bintools = selfDarwin.binutils-unwrapped;
# Bootstrap tools cctools needs the hook and wrappers to make sure things are signed properly.
# This can be dropped once the bootstrap tools cctools has been updated to 1010.6.
extraBuildCommands = ''
echo 'source ${selfDarwin.postLinkSignHook}' >> $out/nix-support/post-link-hook
export signingUtils=${selfDarwin.signingUtils}
wrap \
install_name_tool ${../../build-support/bintools-wrapper/darwin-install_name_tool-wrapper.sh} \
"${selfDarwin.binutils-unwrapped}/bin/install_name_tool"
wrap \
strip ${../../build-support/bintools-wrapper/darwin-strip-wrapper.sh} \
"${selfDarwin.binutils-unwrapped}/bin/strip"
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
'';
};
binutils-unwrapped =
(superDarwin.binutils-unwrapped.overrideAttrs (old: {
version = "boot";
passthru = (old.passthru or { }) // {
isFromBootstrapFiles = true;
};
})).override
{ enableManpages = false; };
locale = self.stdenv.mkDerivation {
name = "bootstrap-stage0-locale";
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
buildCommand = ''
mkdir -p $out/share/locale
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
'';
};
print-reexports = bootstrapTools;
rewrite-tbd = bootstrapTools;
sigtool = bootstrapTools;
}
// lib.optionalAttrs (!useAppleSDKLibs) {
Libsystem = self.stdenv.mkDerivation {
name = "bootstrap-stage0-Libsystem";
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
buildCommand = ''
mkdir -p $out
cp -r ${selfDarwin.darwin-stubs}/usr/lib $out/lib
chmod -R +w $out/lib
substituteInPlace $out/lib/libSystem.B.tbd --replace /usr/lib/system $out/lib/system
ln -s libSystem.B.tbd $out/lib/libSystem.tbd
for name in c dbm dl info m mx poll proc pthread rpcsvc util gcc_s.10.4 gcc_s.10.5; do
ln -s libSystem.tbd $out/lib/lib$name.tbd
done
ln -s ${bootstrapTools}/lib/*.o $out/lib
ln -s ${bootstrapTools}/lib/libresolv.9.dylib $out/lib
ln -s libresolv.9.dylib $out/lib/libresolv.dylib
ln -s ${bootstrapTools}/include-Libsystem $out/include
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
'';
passthru.isFromBootstrapFiles = true;
};
}
);
llvmPackages =
super.llvmPackages
// (
let
tools = super.llvmPackages.tools.extend (
selfTools: _: {
libclang = self.stdenv.mkDerivation {
name = "bootstrap-stage0-clang";
version = "boot";
outputs = [
"out"
"lib"
];
buildCommand = ''
mkdir -p $out/lib
ln -s $out $lib
ln -s ${bootstrapTools}/bin $out/bin
ln -s ${bootstrapTools}/lib/clang $out/lib
ln -s ${bootstrapTools}/include $out
'';
passthru = {
isFromBootstrapFiles = true;
hardeningUnsupportedFlags = [
"fortify3"
"shadowstack"
"stackclashprotection"
"zerocallusedregs"
];
};
};
libllvm = self.stdenv.mkDerivation {
name = "bootstrap-stage0-llvm";
outputs = [
"out"
"lib"
];
buildCommand = ''
mkdir -p $out/bin $out/lib
ln -s $out $lib
for tool in ${toString super.darwin.binutils-unwrapped.llvm_cmds}; do
cctoolsTool=''${tool//-/_}
toolsrc="${bootstrapTools}/bin/$cctoolsTool"
if [ -e "$toolsrc" ]; then
ln -s "$toolsrc" $out/bin/llvm-$tool
fi
done
ln -s ${bootstrapTools}/bin/dsymutil $out/bin/dsymutil
ln -s ${bootstrapTools}/lib/libLLVM* $out/lib
'';
passthru.isFromBootstrapFiles = true;
};
}
);
libraries = super.llvmPackages.libraries.extend (
_: _: {
libcxx = self.stdenv.mkDerivation {
name = "bootstrap-stage0-libcxx";
buildCommand = ''
mkdir -p $out/lib $out/include
ln -s ${bootstrapTools}/lib/libc++.dylib $out/lib
ln -s ${bootstrapTools}/include/c++ $out/include
'';
passthru = {
isLLVM = true;
isFromBootstrapFiles = true;
};
};
compiler-rt = self.stdenv.mkDerivation {
name = "bootstrap-stage0-compiler-rt";
buildCommand = ''
mkdir -p $out/lib $out/share
ln -s ${bootstrapTools}/lib/libclang_rt* $out/lib
ln -s ${bootstrapTools}/lib/darwin $out/lib
'';
passthru.isFromBootstrapFiles = true;
};
}
);
in
{ inherit tools libraries; } // tools // libraries
);
};
extraPreHook = ''
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
'';
}
)
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# This stage is primarily responsible for setting up versions of certain dependencies needed
# by the rest of the build process. This stage also builds CF and Libsystem to simplify assertions
# and assumptions for later by making sure both packages are present on x86_64-darwin and aarch64-darwin.
(
prevStage:
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# previous stage0 stdenv:
darwin.stdenv: use CoreFoundation instead of CF This patch switches the CoreFoundation on x86_64-darwin from the open source swift-corelibs-foundation (CF) to the system CoreFoundation. This change was motivated by failures building packages for the current staging-next cycle #263535 due to an apparent incompatibility with the rpath-based approach to choosing CF or CoreFoundation and macOS 14. This error often manifests as a crash with an Illegal Instruction. For example, building aws-sdk-cpp for building Nix will fail this way. https://hydra.nixos.org/build/239459417/nixlog/1 Application Specific Information: CF objects must have a non-zero isa Error Formulating Crash Report: PC register does not match crashing frame (0x0 vs 0x7FF8094DD640) Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 CoreFoundation 0x7ff8094dd640 CF_IS_OBJC.cold.1 + 14 1 CoreFoundation 0x7ff8094501d0 CF_IS_OBJC + 60 2 CoreFoundation 0x7ff8093155e8 CFRelease + 40 3 ??? 0x10c7a2c61 s_aws_secure_transport_ctx_destroy + 65 4 ??? 0x10c87ba32 aws_ref_count_release + 34 5 ??? 0x10c7b7adb aws_tls_connection_options_clean_up + 27 6 ??? 0x10c596db4 Aws::Crt::Io::TlsConnectionOptions::~TlsConnectionOptions() + 20 7 ??? 0x10c2d249c Aws::CleanupCrt() + 92 8 ??? 0x10c2d1ff0 Aws::ShutdownAPI(Aws::SDKOptions const&) + 64 9 ??? 0x102d9bc6f main + 335 10 dyld 0x202f333a6 start + 1942 According to a [post][1] on the Apple developer forums, hardening was added to CoreFoundation, and this particular message occurs when you attempt to release an object it does not recognize as a valid CF object. (Thank you to @lilyinstarlight for finding this post). When I switched aws-sdk-cpp to link against CoreFoundation instead of CF, the error went away. Somehow both libraries were being used. To prevent dependent packages from linking the wrong CoreFoundation, it would need to be added as a propagated build input. Note that there are other issues related to mixing CF and CoreFoundation frameworks. #264503 fixes an issue with abseil-cpp where it propagates CF, causing issues when using a different SDK version. Mixing versions can also cause crashes with Python when a shared object is loaded that is linked to the “wrong” CoreFoundation. `NIX_COREFOUNDATION_RPATH` is supposed to make sure the right CoreFoundation is being used, but it does not appear to be enough on macOS 14 (presumably due to the hardening). While it is possible to propagate CoreFoundation manually, the cleaner solution is to make it the default. CF remains available as `darwin.swift-corelibs-foundation`. [1]: https://developer.apple.com/forums/thread/739355
2023-11-02 00:56:50 +00:00
assert lib.all isFromBootstrapFiles (
with prevStage;
[
bash
cctools
coreutils
cpio
gnugrep
ld64
]
++ lib.optionals useAppleSDKLibs [ pbzx ]
darwin.stdenv: use CoreFoundation instead of CF This patch switches the CoreFoundation on x86_64-darwin from the open source swift-corelibs-foundation (CF) to the system CoreFoundation. This change was motivated by failures building packages for the current staging-next cycle #263535 due to an apparent incompatibility with the rpath-based approach to choosing CF or CoreFoundation and macOS 14. This error often manifests as a crash with an Illegal Instruction. For example, building aws-sdk-cpp for building Nix will fail this way. https://hydra.nixos.org/build/239459417/nixlog/1 Application Specific Information: CF objects must have a non-zero isa Error Formulating Crash Report: PC register does not match crashing frame (0x0 vs 0x7FF8094DD640) Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 CoreFoundation 0x7ff8094dd640 CF_IS_OBJC.cold.1 + 14 1 CoreFoundation 0x7ff8094501d0 CF_IS_OBJC + 60 2 CoreFoundation 0x7ff8093155e8 CFRelease + 40 3 ??? 0x10c7a2c61 s_aws_secure_transport_ctx_destroy + 65 4 ??? 0x10c87ba32 aws_ref_count_release + 34 5 ??? 0x10c7b7adb aws_tls_connection_options_clean_up + 27 6 ??? 0x10c596db4 Aws::Crt::Io::TlsConnectionOptions::~TlsConnectionOptions() + 20 7 ??? 0x10c2d249c Aws::CleanupCrt() + 92 8 ??? 0x10c2d1ff0 Aws::ShutdownAPI(Aws::SDKOptions const&) + 64 9 ??? 0x102d9bc6f main + 335 10 dyld 0x202f333a6 start + 1942 According to a [post][1] on the Apple developer forums, hardening was added to CoreFoundation, and this particular message occurs when you attempt to release an object it does not recognize as a valid CF object. (Thank you to @lilyinstarlight for finding this post). When I switched aws-sdk-cpp to link against CoreFoundation instead of CF, the error went away. Somehow both libraries were being used. To prevent dependent packages from linking the wrong CoreFoundation, it would need to be added as a propagated build input. Note that there are other issues related to mixing CF and CoreFoundation frameworks. #264503 fixes an issue with abseil-cpp where it propagates CF, causing issues when using a different SDK version. Mixing versions can also cause crashes with Python when a shared object is loaded that is linked to the “wrong” CoreFoundation. `NIX_COREFOUNDATION_RPATH` is supposed to make sure the right CoreFoundation is being used, but it does not appear to be enough on macOS 14 (presumably due to the hardening). While it is possible to propagate CoreFoundation manually, the cleaner solution is to make it the default. CF remains available as `darwin.swift-corelibs-foundation`. [1]: https://developer.apple.com/forums/thread/739355
2023-11-02 00:56:50 +00:00
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.all isFromBootstrapFiles (
with prevStage.darwin;
[
binutils-unwrapped
print-reexports
rewrite-tbd
sigtool
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert (!useAppleSDKLibs) -> lib.all isFromBootstrapFiles (with prevStage.darwin; [ Libsystem ]);
assert useAppleSDKLibs -> lib.all isFromNixpkgs (with prevStage.darwin; [ Libsystem ]);
assert lib.all isFromNixpkgs (
with prevStage.darwin;
[
dyld
launchd
xnu
]
);
assert (with prevStage.darwin; (!useAppleSDKLibs) -> CF == null);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.all isFromBootstrapFiles (
with prevStage.llvmPackages;
[
clang-unwrapped
libclang
libllvm
llvm
compiler-rt
libcxx
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
stageFun prevStage {
name = "bootstrap-stage1";
overrides = self: super: {
inherit (prevStage)
ccWrapperStdenv
cctools
coreutils
gnugrep
ld64
;
binutils-unwrapped = builtins.throw "nothing in the Darwin bootstrap should depend on GNU binutils";
curl = builtins.throw "nothing in the Darwin bootstrap can depend on curl";
# Use this stages CF to build CMake. Its required but cant be included in the stdenv.
cmake = self.cmakeMinimal;
cmakeMinimal = super.cmakeMinimal.overrideAttrs (old: {
buildInputs = old.buildInputs ++ [ self.darwin.CF ];
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# Disable tests because they use dejagnu, which fails to run.
libffi = super.libffi.override { doCheck = false; };
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# Use libconvReal to break an infinite recursion. It will be dropped in the next stage.
libiconv = super.libiconvReal;
# Avoid pulling in a full python and its extra dependencies for the llvm/clang builds.
libxml2 = super.libxml2.override { pythonSupport = false; };
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
ninja = super.ninja.override { buildDocs = false; };
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# Use this stages CF to build Python. Its required, but it cant be included in the stdenv.
python3 = self.python3Minimal;
python3Minimal =
(super.python3Minimal.override { self = self.python3Minimal; }).overrideAttrs
(old: {
buildInputs = old.buildInputs or [ ] ++ [ self.darwin.CF ];
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
scons = super.scons.override { python3Packages = self.python3Minimal.pkgs; };
darwin = super.darwin.overrideScope (
selfDarwin: superDarwin: {
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
# Use this stages CF to build configd. Its required, but it cant be included in the stdenv.
configd = superDarwin.configd.overrideAttrs (old: {
buildInputs = old.buildInputs or [ ] ++ [ self.darwin.CF ];
});
darwin.stdenv: use CoreFoundation instead of CF This patch switches the CoreFoundation on x86_64-darwin from the open source swift-corelibs-foundation (CF) to the system CoreFoundation. This change was motivated by failures building packages for the current staging-next cycle #263535 due to an apparent incompatibility with the rpath-based approach to choosing CF or CoreFoundation and macOS 14. This error often manifests as a crash with an Illegal Instruction. For example, building aws-sdk-cpp for building Nix will fail this way. https://hydra.nixos.org/build/239459417/nixlog/1 Application Specific Information: CF objects must have a non-zero isa Error Formulating Crash Report: PC register does not match crashing frame (0x0 vs 0x7FF8094DD640) Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 CoreFoundation 0x7ff8094dd640 CF_IS_OBJC.cold.1 + 14 1 CoreFoundation 0x7ff8094501d0 CF_IS_OBJC + 60 2 CoreFoundation 0x7ff8093155e8 CFRelease + 40 3 ??? 0x10c7a2c61 s_aws_secure_transport_ctx_destroy + 65 4 ??? 0x10c87ba32 aws_ref_count_release + 34 5 ??? 0x10c7b7adb aws_tls_connection_options_clean_up + 27 6 ??? 0x10c596db4 Aws::Crt::Io::TlsConnectionOptions::~TlsConnectionOptions() + 20 7 ??? 0x10c2d249c Aws::CleanupCrt() + 92 8 ??? 0x10c2d1ff0 Aws::ShutdownAPI(Aws::SDKOptions const&) + 64 9 ??? 0x102d9bc6f main + 335 10 dyld 0x202f333a6 start + 1942 According to a [post][1] on the Apple developer forums, hardening was added to CoreFoundation, and this particular message occurs when you attempt to release an object it does not recognize as a valid CF object. (Thank you to @lilyinstarlight for finding this post). When I switched aws-sdk-cpp to link against CoreFoundation instead of CF, the error went away. Somehow both libraries were being used. To prevent dependent packages from linking the wrong CoreFoundation, it would need to be added as a propagated build input. Note that there are other issues related to mixing CF and CoreFoundation frameworks. #264503 fixes an issue with abseil-cpp where it propagates CF, causing issues when using a different SDK version. Mixing versions can also cause crashes with Python when a shared object is loaded that is linked to the “wrong” CoreFoundation. `NIX_COREFOUNDATION_RPATH` is supposed to make sure the right CoreFoundation is being used, but it does not appear to be enough on macOS 14 (presumably due to the hardening). While it is possible to propagate CoreFoundation manually, the cleaner solution is to make it the default. CF remains available as `darwin.swift-corelibs-foundation`. [1]: https://developer.apple.com/forums/thread/739355
2023-11-02 00:56:50 +00:00
signingUtils = prevStage.darwin.signingUtils.override { inherit (selfDarwin) sigtool; };
postLinkSignHook = prevStage.darwin.postLinkSignHook.override { inherit (selfDarwin) sigtool; };
2023-07-08 09:44:20 +00:00
# Rewrap binutils with the real Libsystem
binutils = superDarwin.binutils.override {
inherit (self) coreutils;
bintools = selfDarwin.binutils-unwrapped;
libc = selfDarwin.Libsystem;
# TODO(@sternenseemann): can this be removed?
runtimeShell = "${bootstrapTools}/bin/bash";
# Bootstrap tools cctools needs the hook to make sure things are signed properly.
# This can be dropped once the bootstrap tools cctools has been updated to 1010.6.
extraBuildCommands = ''
echo 'source ${selfDarwin.postLinkSignHook}' >> $out/nix-support/post-link-hook
export signingUtils=${selfDarwin.signingUtils}
wrap \
install_name_tool ${../../build-support/bintools-wrapper/darwin-install_name_tool-wrapper.sh} \
"${selfDarwin.binutils-unwrapped}/bin/install_name_tool"
wrap \
strip ${../../build-support/bintools-wrapper/darwin-strip-wrapper.sh} \
"${selfDarwin.binutils-unwrapped}/bin/strip"
'';
};
# Avoid building unnecessary Python dependencies due to building LLVM manpages.
binutils-unwrapped = superDarwin.binutils-unwrapped.override {
inherit (self) cctools ld64;
enableManpages = false;
};
}
);
llvmPackages =
super.llvmPackages
// (
let
tools = super.llvmPackages.tools.extend (
_: _: {
inherit (prevStage.llvmPackages)
clang-unwrapped
libclang
libllvm
llvm
;
}
);
libraries = super.llvmPackages.libraries.extend (
_: _: { inherit (prevStage.llvmPackages) compiler-rt libcxx; }
);
in
{
inherit tools libraries;
inherit (prevStage.llvmPackages) release_version;
}
// tools
// libraries
);
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
extraPreHook = ''
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
'';
}
)
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# Build sysctl for use by LLVMs check phase. It must be built separately to avoid an infinite recursion.
(
prevStage:
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# previous stage1 stdenv:
assert lib.all isFromBootstrapFiles (
with prevStage;
[
cctools
coreutils
gnugrep
ld64
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage;
[
autoconf
automake
bash
bison
brotli
cmake
cpio
cyrus_sasl
db
ed
expat
flex
gettext
gmp
groff
icu
libedit
libffi
libiconv
libidn2
libkrb5
libssh2
libtool
libunistring
libxml2
m4
ncurses
nghttp2
ninja
openldap
openssh
openssl
patchutils
pbzx
perl
pkg-config.pkg-config
python3
python3Minimal
scons
serf
sqlite
subversion
texinfo
unzip
which
xz
zlib
zstd
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage.darwin;
[
locale
print-reexports
rewrite-tbd
sigtool
]
);
assert
(!useAppleSDKLibs)
-> lib.all isBuiltByBootstrapFilesCompiler (
with prevStage.darwin;
[
Libsystem
configd
]
);
assert (!useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
assert
useAppleSDKLibs
-> lib.all isFromNixpkgs (
with prevStage.darwin;
[
CF
Libsystem
libobjc
]
);
assert lib.all isFromNixpkgs (
with prevStage.darwin;
[
binutils-unwrapped
dyld
launchd
xnu
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.all isFromBootstrapFiles (
with prevStage.llvmPackages;
[
clang-unwrapped
libclang
libllvm
llvm
compiler-rt
libcxx
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.getVersion prevStage.stdenv.cc.bintools.bintools == "boot";
stageFun prevStage {
name = "bootstrap-stage1-sysctl";
overrides = self: super: {
inherit (prevStage)
ccWrapperStdenv
autoconf
automake
bash
binutils-unwrapped
bison
brotli
cctools
cmake
cmakeMinimal
coreutils
cpio
curl
cyrus_sasl
db
ed
expat
flex
gettext
gmp
gnugrep
groff
icu
ld64
libedit
libffi
libidn2
libkrb5
libssh2
libtool
libunistring
libxml2
m4
ncurses
nghttp2
ninja
openldap
openssh
openssl
patchutils
pbzx
perl
pkg-config
python3Minimal
scons
sed
serf
sharutils
sqlite
subversion
texinfo
unzip
which
xz
zlib
zstd
;
# Avoid pulling in openldap just to run Mesons tests.
meson = super.meson.overrideAttrs { doInstallCheck = false; };
# The bootstrap Python needs its own `pythonAttr` to make sure the override works properly.
python3 = self.python3-bootstrap;
python3-bootstrap = super.python3.override {
self = self.python3-bootstrap;
pythonAttr = "python3-bootstrap";
enableLTO = false;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
darwin = super.darwin.overrideScope (
_: superDarwin: {
inherit (prevStage.darwin)
CF
sdkRoot
Libsystem
binutils
binutils-unwrapped
configd
darwin-stubs
dtrace
dyld
launchd
libclosure
libdispatch
libobjc
locale
objc4
postLinkSignHook
print-reexports
rewrite-tbd
signingUtils
sigtool
;
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
}
);
llvmPackages =
super.llvmPackages
// (
let
tools = super.llvmPackages.tools.extend (
_: _: {
inherit (prevStage.llvmPackages)
clang-unwrapped
libclang
libllvm
llvm
;
clang = prevStage.stdenv.cc;
}
);
libraries = super.llvmPackages.libraries.extend (
_: _: { inherit (prevStage.llvmPackages) compiler-rt libcxx; }
);
in
{
inherit tools libraries;
inherit (prevStage.llvmPackages) release_version;
}
// tools
// libraries
);
};
2020-11-19 08:28:20 +00:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
extraPreHook = ''
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
'';
}
)
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# First rebuild of LLVM. While this LLVM is linked to a bunch of junk from the bootstrap tools,
# the libc++ and libc++abi it produces are not. The compiler will be rebuilt in a later stage,
# but those libraries will be used in the final stdenv.
#
# Rebuild coreutils and gnugrep to avoid unwanted references to the bootstrap tools on `PATH`.
#
# The first build of cctools is deferred until this stage because it depends on LLVM headers
# that are not included in the bootstrap tools tarball.
(
prevStage:
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# previous stage-sysctl stdenv:
assert lib.all isFromBootstrapFiles (
with prevStage;
[
cctools
coreutils
gnugrep
ld64
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage;
[
atf
autoconf
automake
bash
bison
brotli
cmake
cpio
cyrus_sasl
db
ed
expat
flex
gettext
gmp
groff
icu
kyua
libedit
libffi
libiconv
libidn2
libkrb5
libssh2
libtapi
libtool
libunistring
libxml2
m4
meson
ncurses
nghttp2
ninja
openldap
openssh
openssl
patchutils
pbzx
perl
pkg-config.pkg-config
python3
python3Minimal
scons
serf
sqlite
subversion
sysctl.provider
texinfo
unzip
which
xz
zlib
zstd
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage.darwin;
[
locale
print-reexports
rewrite-tbd
sigtool
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert
(!useAppleSDKLibs)
-> lib.all isBuiltByBootstrapFilesCompiler (
with prevStage.darwin;
[
Libsystem
configd
]
);
assert (!useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
assert
useAppleSDKLibs
-> lib.all isFromNixpkgs (
with prevStage.darwin;
[
CF
Libsystem
libobjc
]
);
assert lib.all isFromNixpkgs (
with prevStage.darwin;
[
binutils-unwrapped
dyld
launchd
xnu
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.all isFromBootstrapFiles (
with prevStage.llvmPackages;
[
clang-unwrapped
libclang
libllvm
llvm
compiler-rt
libcxx
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
stageFun prevStage {
name = "bootstrap-stage-xclang";
overrides = self: super: {
inherit (prevStage)
ccWrapperStdenv
atf
autoconf
automake
bash
binutils-unwrapped
bison
brotli
cmake
cmakeMinimal
cpio
curl
cyrus_sasl
db
ed
expat
flex
gettext
gmp
groff
icu
kyua
libedit
libffi
libiconv
libidn2
libkrb5
libssh2
libtool
libunistring
libxml2
m4
meson
ncurses
nghttp2
ninja
openldap
openssh
openssl
patchutils
pbzx
perl
pkg-config
python3
python3Minimal
scons
sed
serf
sharutils
sqlite
subversion
sysctl
texinfo
unzip
which
xz
zlib
zstd
;
# Disable ld64s install check phase because the required LTO libraries are not built yet.
ld64 = super.ld64.overrideAttrs { doInstallCheck = false; };
darwin = super.darwin.overrideScope (
selfDarwin: superDarwin: {
inherit (prevStage.darwin)
CF
Libsystem
configd
darwin-stubs
dyld
launchd
libclosure
libdispatch
libobjc
locale
objc4
postLinkSignHook
print-reexports
rewrite-tbd
signingUtils
sigtool
;
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
binutils = superDarwin.binutils.override {
inherit (prevStage) expand-response-params;
libc = selfDarwin.Libsystem;
};
# Avoid building unnecessary Python dependencies due to building LLVM manpages.
binutils-unwrapped = superDarwin.binutils-unwrapped.override { enableManpages = false; };
}
);
llvmPackages =
super.llvmPackages
// (
let
llvmMajor = lib.versions.major super.llvmPackages.release_version;
# libc++, and libc++abi do not need CoreFoundation. Avoid propagating the CF from prior
# stages to the final stdenv via rpath by dropping it from `extraBuildInputs`.
stdenvNoCF = self.stdenv.override { extraBuildInputs = [ ]; };
libcxxBootstrapStdenv = self.overrideCC stdenvNoCF (
self.llvmPackages.clangNoCompilerRtWithLibc.override {
nixSupport.cc-cflags = [ "-nostdlib" ];
nixSupport.cc-ldflags = [ "-lSystem" ];
}
);
tools = super.llvmPackages.tools.extend (
selfTools: superTools: {
# LLVMs check phase takes a while to run, so disable it in the first LLVM build to speed up the bootstrap.
libllvm = superTools.libllvm.override { doCheck = false; };
}
);
libraries = super.llvmPackages.libraries.extend (
selfLib: superLib: {
compiler-rt = null;
libcxx = superLib.libcxx.override ({ stdenv = libcxxBootstrapStdenv; });
}
);
in
{ inherit tools libraries; } // tools // libraries
);
};
2020-11-19 08:28:20 +00:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
extraPreHook = ''
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
'';
}
)
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# This stage rebuilds Libsystem. It also rebuilds bash, which will be needed in later stages
# to use in patched shebangs (e.g., to make sure `icu-config` uses bash from nixpkgs).
(
prevStage:
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# previous stage-xclang stdenv:
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage;
[
atf
autoconf
automake
bash
bison
cctools
cmake
cmakeMinimal
coreutils
cpio
cyrus_sasl
db
ed
expat
flex
gettext
gmp
gnugrep
groff
icu
kyua
ld64
libedit
libtapi
libtool
m4
meson
ninja
openbsm
openldap
openpam
openssh
patchutils
pbzx
perl
pkg-config.pkg-config
python3
python3Minimal
scons
serf
sqlite
subversion
sysctl.provider
texinfo
unzip
which
xz
]
);
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage;
[
brotli
libffi
libiconv
libidn2
libkrb5
libssh2
libunistring
libxml2
ncurses
nghttp2
openssl
zlib
zstd
]
);
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage.darwin;
[
locale
print-reexports
rewrite-tbd
sigtool
]
);
assert
(!useAppleSDKLibs)
-> lib.all isBuiltByBootstrapFilesCompiler (
with prevStage.darwin;
[
Libsystem
configd
]
);
assert (!useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
assert
useAppleSDKLibs
-> lib.all isFromNixpkgs (
with prevStage.darwin;
[
CF
Libsystem
libobjc
]
);
assert lib.all isFromNixpkgs (
with prevStage.darwin;
[
binutils-unwrapped
dyld
launchd
libclosure
libdispatch
xnu
]
);
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage.llvmPackages;
[
clang-unwrapped
libclang
libllvm
llvm
]
);
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 10:53:37 +00:00
assert lib.all isBuiltByNixpkgsCompiler (with prevStage.llvmPackages; [ libcxx ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert prevStage.llvmPackages.compiler-rt == null;
stageFun prevStage {
name = "bootstrap-stage2";
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
overrides = self: super: {
inherit (prevStage)
ccWrapperStdenv
atf
autoconf
automake
binutils-unwrapped
bison
brotli
cctools
cmake
cmakeMinimal
coreutils
cpio
curl
cyrus_sasl
db
ed
expat
flex
gettext
gmp
gnugrep
groff
icu
kyua
ld64
libedit
libffi
libiconv
libidn2
libkrb5
libssh2
libtapi
libtool
libunistring
libxml2
m4
meson
ncurses
nghttp2
ninja
openbsm
openldap
openpam
openssh
openssl
patchutils
pbzx
perl
pkg-config
python3
python3Minimal
scons
serf
sqlite
subversion
sysctl
texinfo
unzip
which
xz
zlib
zstd
;
# Bash must be linked against the system CoreFoundation instead of the open-source one.
# Otherwise, there will be a dependency cycle: bash -> CF -> icu -> bash (for icu^dev).
bash = super.bash.overrideAttrs (super: {
buildInputs = super.buildInputs ++ [ self.darwin.apple_sdk.frameworks.CoreFoundation ];
});
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
darwin = super.darwin.overrideScope (
selfDarwin: superDarwin: {
inherit (prevStage.darwin)
binutils-unwrapped
configd
darwin-stubs
launchd
locale
postLinkSignHook
print-reexports
rewrite-tbd
signingUtils
sigtool
;
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# Rewrap binutils so it uses the rebuilt Libsystem.
binutils =
superDarwin.binutils.override {
inherit (prevStage) expand-response-params;
libc = selfDarwin.Libsystem;
}
// {
passthru = {
inherit (prevStage.bintools.passthru) isFromBootstrapFiles;
};
2021-06-02 04:25:56 +00:00
};
}
);
2021-06-02 04:25:56 +00:00
llvmPackages =
super.llvmPackages
// (
let
tools = super.llvmPackages.tools.extend (
_: _: {
inherit (prevStage.llvmPackages)
clang-unwrapped
clangNoCompilerRtWithLibc
libclang
lld
libllvm
llvm
;
}
);
libraries = super.llvmPackages.libraries.extend (
selfLib: superLib: {
inherit (prevStage.llvmPackages) libcxx;
# Make sure compiler-rt is linked against the CF from this stage, which can be
# propagated to the final stdenv. CF is required by ASAN.
compiler-rt = superLib.compiler-rt.override ({
inherit (self.llvmPackages) libllvm;
stdenv = self.stdenv.override { extraBuildInputs = [ self.darwin.CF ]; };
});
}
);
in
{
inherit tools libraries;
inherit (prevStage.llvmPackages) release_version;
}
// tools
// libraries
);
# Dont link anything in this stage against CF to prevent propagating CF from prior stages to
# the final stdenv, which happens because of the rpath hook.
stdenv =
let
stdenvNoCF = super.stdenv.override { extraBuildInputs = [ ]; };
in
self.overrideCC stdenvNoCF (
self.llvmPackages.clangNoCompilerRtWithLibc.override { inherit (self.llvmPackages) libcxx; }
);
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
extraPreHook = ''
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
'';
}
)
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# Rebuild LLVM with LLVM. This stage also rebuilds certain dependencies needed by LLVM.
#
# LLVM requires: libcxx libffi libiconv libxml2 ncurses python3 zlib
(
prevStage:
# previous stage2 stdenv:
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage;
[
autoconf
automake
bison
brotli
cctools
cmake
cmakeMinimal
coreutils
cpio
cyrus_sasl
db
ed
expat
flex
gettext
gmp
gnugrep
groff
icu
ld64
libedit
libffi
libiconv
libidn2
libkrb5
libssh2
libtool
libtapi
libunistring
libxml2
m4
meson
ncurses
nghttp2
ninja
openbsm
openldap
openpam
openssh
openssl
patchutils
pbzx
perl
pkg-config.pkg-config
python3
python3Minimal
scons
serf
sqlite
subversion
sysctl.provider
texinfo
unzip
which
xz
zstd
zlib
]
);
assert lib.all isBuiltByNixpkgsCompiler (with prevStage; [ bash ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage.darwin;
[
locale
print-reexports
rewrite-tbd
sigtool
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert
(!useAppleSDKLibs) -> lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [ configd ]);
assert
(!useAppleSDKLibs) -> lib.all isBuiltByNixpkgsCompiler (with prevStage.darwin; [ Libsystem ]);
assert (!useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
assert
useAppleSDKLibs
-> lib.all isFromNixpkgs (
with prevStage.darwin;
[
CF
Libsystem
libobjc
]
);
assert lib.all isFromNixpkgs (
with prevStage.darwin;
[
binutils-unwrapped
dyld
launchd
libclosure
libdispatch
xnu
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage.llvmPackages;
[
clang-unwrapped
libclang
libllvm
llvm
]
);
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043) - merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git. - remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required. - fixes https://github.com/NixOS/nixpkgs/issues/166205 - provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640 - pkgsCross.x86_64-freebsd builds work again This change can be represented in 3 stages 1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi} 2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin} 3. remove all references to libcxxabi outside of llvm (about 58 packages modified) ### merging libcxxabi into libcxx - take the union of the libcxxabi and libcxx cmake flags - eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency - libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx. - darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient. - linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient. - libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+) - git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway. ### stdenv changes - darwin bootstrap, remove references to libcxxabi and cxxabi - cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12) - adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx ### 58 package updates - remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed - swift, nodejs_v8 remove libcxxabi references in the clang override https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 10:53:37 +00:00
assert lib.all isBuiltByNixpkgsCompiler (with prevStage.llvmPackages; [ libcxx ]);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
stageFun prevStage {
name = "bootstrap-stage3";
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
overrides = self: super: {
inherit (prevStage)
ccWrapperStdenv
autoconf
automake
bash
binutils-unwrapped
bison
brotli
cmake
cmakeMinimal
coreutils
cpio
curl
cyrus_sasl
db
ed
expat
flex
gettext
gmp
gnugrep
groff
libedit
libidn2
libkrb5
libssh2
libtool
libunistring
m4
meson
nghttp2
ninja
openbsm
openldap
openpam
openssh
openssl
patchutils
pbzx
perl
pkg-config
python3
python3Minimal
scons
sed
serf
sharutils
sqlite
subversion
sysctl
texinfo
unzip
which
xz
zstd
;
# Disable tests because they use dejagnu, which fails to run.
libffi = super.libffi.override { doCheck = false; };
# Avoid pulling in a full python and its extra dependencies for the llvm/clang builds.
libxml2 = super.libxml2.override { pythonSupport = false; };
darwin = super.darwin.overrideScope (
selfDarwin: superDarwin: {
inherit (prevStage.darwin)
CF
Libsystem
binutils
binutils-unwrapped
configd
darwin-stubs
dyld
launchd
libclosure
libdispatch
libobjc
locale
objc4
postLinkSignHook
print-reexports
rewrite-tbd
signingUtils
sigtool
;
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
}
);
llvmPackages =
super.llvmPackages
// (
let
libraries = super.llvmPackages.libraries.extend (
_: _: { inherit (prevStage.llvmPackages) compiler-rt libcxx; }
);
in
{ inherit libraries; } // libraries
);
};
2020-11-19 08:28:20 +00:00
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
extraPreHook = ''
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
'';
}
)
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# Construct a standard environment with the new clang. Also use the new compiler to rebuild
# everything that will be part of the final stdenv and isnt required by it, CF, or Libsystem.
(
prevStage:
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# previous stage3 stdenv:
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage;
[
autoconf
automake
bison
brotli
cmake
cmakeMinimal
coreutils
cpio
cyrus_sasl
db
ed
expat
flex
gettext
gmp
gnugrep
groff
libedit
libidn2
libkrb5
libssh2
libtool
libunistring
m4
meson
nghttp2
ninja
openbsm
openldap
openpam
openssh
openssl
patchutils
pbzx
perl
pkg-config.pkg-config
python3
python3Minimal
scons
serf
sqlite
subversion
sysctl.provider
texinfo
unzip
which
xz
zstd
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.all isBuiltByNixpkgsCompiler (
with prevStage;
[
bash
cctools
icu
ld64
libtapi
libffi
libiconv
libxml2
zlib
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage.darwin;
[
locale
print-reexports
rewrite-tbd
sigtool
]
);
2020-11-19 08:28:20 +00:00
assert
(!useAppleSDKLibs) -> lib.all isBuiltByBootstrapFilesCompiler (with prevStage.darwin; [ configd ]);
assert
(!useAppleSDKLibs) -> lib.all isBuiltByNixpkgsCompiler (with prevStage.darwin; [ Libsystem ]);
assert (!useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
assert
useAppleSDKLibs
-> lib.all isFromNixpkgs (
with prevStage.darwin;
[
CF
Libsystem
libobjc
]
);
assert lib.all isFromNixpkgs (
with prevStage.darwin;
[
binutils-unwrapped
dyld
launchd
libclosure
libdispatch
xnu
]
);
2021-06-02 04:25:56 +00:00
assert lib.all isBuiltByNixpkgsCompiler (
with prevStage.llvmPackages;
[
clang-unwrapped
libclang
libllvm
llvm
compiler-rt
libcxx
]
);
stageFun prevStage {
2021-06-02 04:25:56 +00:00
name = "bootstrap-stage4";
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
overrides = self: super: {
inherit (prevStage)
ccWrapperStdenv
autoconf
automake
bash
binutils-unwrapped
bison
cmake
cmakeMinimal
curl
cyrus_sasl
db
expat
flex
groff
libedit
libtool
m4
meson
ninja
openldap
openssh
patchutils
perl
pkg-config
python3
python3Minimal
scons
serf
sqlite
subversion
sysctl
texinfo
unzip
which
# CF dependencies - dont rebuild them.
icu
# LLVM dependencies - dont rebuild them.
libffi
libiconv
libiconv-darwin
libxml2
ncurses
zlib
;
darwin = super.darwin.overrideScope (
selfDarwin: superDarwin: {
inherit (prevStage.darwin)
dyld
CF
Libsystem
darwin-stubs
# CF dependencies - dont rebuild them.
libobjc
objc4
;
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
signingUtils = superDarwin.signingUtils.override { inherit (selfDarwin) sigtool; };
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
binutils = superDarwin.binutils.override {
inherit (prevStage) expand-response-params;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
bintools = selfDarwin.binutils-unwrapped;
libc = selfDarwin.Libsystem;
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# binutils-unwrapped needs to build the LLVM man pages, which requires a lot of Python stuff
# that ultimately ends up depending on git. Fortunately, the git dependency is only for check
# inputs. The following set of overrides allow the LLVM documentation to be built without
# pulling curl (and other packages like ffmpeg) into the stdenv bootstrap.
binutils-unwrapped = superDarwin.binutils-unwrapped.override (old: {
llvm-manpages = super.llvmPackages.llvm-manpages.override {
python3Packages = self.python3.pkgs.overrideScope (
_: superPython: {
hatch-vcs = superPython.hatch-vcs.overrideAttrs { doInstallCheck = false; };
markdown-it-py = superPython.markdown-it-py.overrideAttrs { doInstallCheck = false; };
mdit-py-plugins = superPython.mdit-py-plugins.overrideAttrs { doInstallCheck = false; };
myst-parser = superPython.myst-parser.overrideAttrs { doInstallCheck = false; };
}
);
};
});
}
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
llvmPackages =
super.llvmPackages
// (
let
tools = super.llvmPackages.tools.extend (
_: _: {
inherit (prevStage.llvmPackages)
clang-unwrapped
libclang
libllvm
llvm
;
libcxxClang = lib.makeOverridable (import ../../build-support/cc-wrapper) {
nativeTools = false;
nativeLibc = false;
inherit (prevStage) expand-response-params;
extraPackages = [ self.llvmPackages.compiler-rt ];
extraBuildCommands =
let
inherit (self.llvmPackages) clang-unwrapped compiler-rt release_version;
# Clang 16+ uses only the major version in resource-root, but older versions use the complete one.
clangResourceRootIncludePath =
clangLib: clangRelease:
let
clangVersion =
if lib.versionAtLeast clangRelease "16" then lib.versions.major clangRelease else clangRelease;
in
"${clangLib}/lib/clang/${clangVersion}/include";
in
''
rsrc="$out/resource-root"
mkdir "$rsrc"
ln -s "${clangResourceRootIncludePath clang-unwrapped.lib release_version}" "$rsrc"
ln -s "${compiler-rt.out}/lib" "$rsrc/lib"
ln -s "${compiler-rt.out}/share" "$rsrc/share"
echo "-resource-dir=$rsrc" >> $out/nix-support/cc-cflags
'';
cc = self.llvmPackages.clang-unwrapped;
bintools = self.darwin.binutils;
isClang = true;
libc = self.darwin.Libsystem;
inherit (self.llvmPackages) libcxx;
inherit lib;
inherit (self)
stdenvNoCC
coreutils
gnugrep
runtimeShell
;
};
}
);
libraries = super.llvmPackages.libraries.extend (
_: _: { inherit (prevStage.llvmPackages) compiler-rt libcxx; }
);
in
{ inherit tools libraries; } // tools // libraries
);
};
extraNativeBuildInputs = lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
];
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
extraPreHook = ''
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
'';
}
)
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# Construct the final stdenv. The version of LLVM provided should match the one defined in
# `all-packages.nix` for Darwin. Nothing should depend on the bootstrap tools or originate from
# the bootstrap tools.
#
# When updating the Darwin stdenv, make sure that the result has no dependency (`nix-store -qR`)
# on `bootstrapTools` or the binutils built in stage 1.
(
prevStage:
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# previous stage4 stdenv:
assert lib.all isBuiltByNixpkgsCompiler (
with prevStage;
[
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
bash
brotli
bzip2
cctools
cpio
2021-06-02 04:25:56 +00:00
diffutils
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
ed
file
findutils
2021-06-02 04:25:56 +00:00
gawk
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
gettext
gmp
2021-06-02 04:25:56 +00:00
gnugrep
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
gnumake
gnused
gnutar
gzip
icu
ld64
libffi
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
libiconv
libidn2
libkrb5
libssh2
libtapi
libunistring
libxml2
libyaml
ncurses
nghttp2
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
openbsm
openpam
openssl
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
patch
pbzx
pcre
xar
xz
zlib
zstd
]
);
assert lib.all isBuiltByNixpkgsCompiler (
with prevStage.darwin;
[
locale
print-reexports
rewrite-tbd
sigtool
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
]
);
assert
(!useAppleSDKLibs)
-> lib.all isBuiltByNixpkgsCompiler (
with prevStage.darwin;
[
Libsystem
configd
]
);
assert (!useAppleSDKLibs) -> lib.all isFromNixpkgs (with prevStage.darwin; [ CF ]);
assert
useAppleSDKLibs
-> lib.all isFromNixpkgs (
with prevStage.darwin;
[
CF
Libsystem
libobjc
]
);
assert lib.all isFromNixpkgs (
with prevStage.darwin;
[
binutils-unwrapped
dyld
launchd
libclosure
libdispatch
xnu
]
);
assert lib.all isBuiltByNixpkgsCompiler (
with prevStage.llvmPackages;
[
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
clang-unwrapped
libclang
libllvm
llvm
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
compiler-rt
2021-06-02 04:25:56 +00:00
libcxx
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
]
);
2021-06-02 04:25:56 +00:00
assert lib.all isBuiltByBootstrapFilesCompiler (
with prevStage;
[
autoconf
automake
bison
cmake
cmakeMinimal
cyrus_sasl
db
expat
flex
groff
libedit
libtool
m4
meson
ninja
openldap
openssh
patchutils
perl
pkg-config.pkg-config
python3
python3Minimal
scons
serf
sqlite
subversion
sysctl.provider
texinfo
unzip
which
]
);
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
let
cc = prevStage.llvmPackages.clang;
in
{
inherit config overlays;
stdenv = import ../generic {
name = "stdenv-darwin";
buildPlatform = localSystem;
hostPlatform = localSystem;
targetPlatform = localSystem;
inherit config;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
preHook = ''
${commonPreHook}
stripDebugFlags="-S" # llvm-strip does not support "-p" for Mach-O
export PATH_LOCALE=${prevStage.darwin.locale}/share/locale
'';
initialPath = ((import ../generic/common-path.nix) { pkgs = prevStage; });
extraNativeBuildInputs =
lib.optionals localSystem.isAarch64 [ prevStage.updateAutotoolsGnuConfigScriptsHook ]
++ [ prevStage.darwin.apple_sdk.sdkRoot ];
extraBuildInputs = [ prevStage.darwin.CF ];
inherit cc;
shell = cc.shell;
inherit (prevStage.stdenv) fetchurlBoot;
extraAttrs =
{
inherit bootstrapTools;
libc = prevStage.darwin.Libsystem;
shellPackage = prevStage.bash;
}
// lib.optionalAttrs useAppleSDKLibs {
# This objc4 will be propagated to all builds using the final stdenv,
# and we shouldn't mix different builds, because they would be
# conflicting LLVM modules. Export it here so we can grab it later.
inherit (prevStage.darwin) objc4;
};
disallowedRequisites = [ bootstrapTools.out ];
allowedRequisites =
(with prevStage; [
bash
bzip2.bin
bzip2.out
cc.expand-response-params
cctools
ld64.out
ld64.lib
libtapi.out
coreutils
darwin.binutils
darwin.binutils.bintools
diffutils
ed
file
findutils
gawk
gettext
gmp.out
gnugrep
gnugrep.pcre2.out
gnumake
gnused
gnutar
gzip
icu.out
libffi.out
libiconv
libunistring.out
libxml2.out
ncurses.dev
ncurses.man
ncurses.out
openbsm
openpam
openssl.out
patch
xar
xz.bin
xz.out
zlib.dev
zlib.out
])
++ lib.optionals localSystem.isAarch64 [
prevStage.updateAutotoolsGnuConfigScriptsHook
prevStage.gnu-config
]
++ (with prevStage.llvmPackages; [
bintools-unwrapped
clang-unwrapped
clang-unwrapped.lib
compiler-rt
compiler-rt.dev
libcxx
libcxx.dev
lld
llvm
llvm.lib
])
++ (
with prevStage.darwin;
[
CF
Libsystem
dyld
locale
apple_sdk.sdkRoot
]
++ lib.optionals useAppleSDKLibs [ objc4 ]
);
__stdenvImpureHostDeps = commonImpureHostDeps;
__extraImpureHostDeps = commonImpureHostDeps;
overrides =
self: super:
{
inherit (prevStage)
bash
brotli
bzip2
coreutils
cpio
diffutils
ed
file
findutils
gawk
gettext
gmp
gnugrep
gnumake
gnused
gnutar
gzip
icu
libffi
libiconv
libiconv-darwin
libidn2
libssh2
libunistring
libxml2
libyaml
ncurses
nghttp2
openbsm
openpam
openssl
patch
pbzx
pcre
python3Minimal
xar
xz
zlib
zstd
;
darwin = super.darwin.overrideScope (
_: superDarwin:
{
inherit (prevStage.darwin)
CF
Libsystem
darwin-stubs
dyld
locale
libobjc
rewrite-tbd
xnu
;
apple_sdk = superDarwin.apple_sdk // {
inherit (prevStage.darwin.apple_sdk) sdkRoot;
};
}
// lib.optionalAttrs (super.stdenv.targetPlatform == localSystem) {
inherit (prevStage.darwin) binutils binutils-unwrapped;
}
);
}
// lib.optionalAttrs (super.stdenv.targetPlatform == localSystem) {
inherit (prevStage) cctools ld64 libtapi;
inherit (prevStage.llvmPackages) clang llvm;
# Need to get rid of these when cross-compiling.
llvmPackages =
super.llvmPackages
// (
let
tools = super.llvmPackages.tools.extend (
_: _: {
inherit (prevStage.llvmPackages)
clang
clang-unwrapped
libclang
libllvm
llvm
;
}
);
libraries = super.llvmPackages.libraries.extend (
_: _: { inherit (prevStage.llvmPackages) compiler-rt libcxx; }
);
in
{ inherit tools libraries; } // tools // libraries
);
};
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
};
}
)
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# This "no-op" stage is just a place to put the assertions about the final stage.
(
prevStage:
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
# previous final stage stdenv:
assert isBuiltByNixpkgsCompiler prevStage.cctools;
assert isBuiltByNixpkgsCompiler prevStage.ld64;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert isBuiltByNixpkgsCompiler prevStage.darwin.sigtool;
assert isBuiltByNixpkgsCompiler prevStage.darwin.print-reexports;
assert isBuiltByNixpkgsCompiler prevStage.darwin.rewrite-tbd;
assert isFromNixpkgs prevStage.darwin.CF;
assert isFromNixpkgs prevStage.darwin.Libsystem;
assert isFromNixpkgs prevStage.darwin.binutils-unwrapped;
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
assert isBuiltByNixpkgsCompiler prevStage.llvmPackages.clang-unwrapped;
assert isBuiltByNixpkgsCompiler prevStage.llvmPackages.libllvm;
assert isBuiltByNixpkgsCompiler prevStage.llvmPackages.libcxx;
assert isBuiltByNixpkgsCompiler prevStage.llvmPackages.compiler-rt;
# Make sure these evaluate since they were disabled explicitly in the bootstrap.
assert isBuiltByNixpkgsCompiler prevStage.binutils-unwrapped;
assert isFromNixpkgs prevStage.binutils-unwrapped.src;
assert isBuiltByNixpkgsCompiler prevStage.curl;
{
inherit (prevStage) config overlays stdenv;
}
)
darwin.stdenv: refactor stdenv definition In preparation for bumping the LLVM used by Darwin, this change refactors and reworks the stdenv build process. When it made sense, existing behaviors were kept to avoid causing any unwanted breakage. However, there are some differences. The reasoning and differences are discussed below. - Improved cycle times - Working on the Darwin stdenv was a tedious process because `allowedRequisites` determined what was allowed between stages. If you made a mistake, you might have to wait a considerable amount of time for the build to fail. Using assertions makes many errors fail at evaluation time and makes moving things around safer and easier to do. - Decoupling from bootstrap tools - The stdenv build process builds as much as it can in the early stages to remove the requirement that the bootstrap tools need bumped in order to bump the stdenv itself. This should lower the barrier to updates and make it easier to bump in the future. It also allows changes to be made without requiring additional tools be added to the bootstrap tools. - Patterned after the Linux stdenv - I tried to follow the patterns established in the Linux stdenv with adaptations made to Darwin’s needs. My hope is this makes the Darwin stdenv more approable for non-Darwin developers who made need to interact with it. It also allowed some of the hacks to be removed. - Documentation - Comments were added explaining what was happening and why things were being done. This is particular important for some stages that might not be obvious (such as the sysctl stage). - Cleanup - Converting the intermediate `allowedRequisites` to assertions revealed that many packages were being referenced that no longer exist or have been renamed. Removing them reduces clutter and should help make the stdenv bootstrap process be more understandable.
2023-05-10 07:03:00 +00:00
]