There is a huge amount of duplication between the cross bootstrap and stdenv/linux. Both of them go through the same dance. The goal is to deduplicate this dance with no loss of functionality.
Here is what the cross bootstrap looks like:
- Build
pkgsBuildBuild.stdenv
- Use
pkgsBuildBuild.stdenv to compile the bintools (bintoolsNoLibc)
- Use
pkgsBuildBuild.stdenv to compile a bare-bones compiler (gccWithoutTargetLibc / clangNoLibc)
- Use the bare-bones compiler to compile the bintools
- Use the bare-bones compiler to compile the libc
- Use the bare-bones compiler to compile real compiler
- Use the real compiler to compile the libc
Here are the native linux stages:
- Unpack the
bootstrap-files
- Use the
bootstrap-files compiler+bintools to compile the bintools
- Use the
bootstrap-files compiler and new bintools to the bare-bones compiler (xgcc)
- Use the bare-bones compiler to compile the bintools
- Use the bare-bones compiler to compile the libc
- Use the bare-bones compiler to compile the real compiler
- Use the real compiler to compile the libc
- Use the real compiler to compile the bintools
The only native bootstrap step that doesn't correspond to anything in the cross bootstrap is the very last one. It exists only because the native bootstrap has a disallowedReferences entry for the bootstrap-files, but cross bootstrap doesn't care about that. This stage would simply be skipped in the cross case. Or we could keep it and add the disallowedReferences check to the cross bootstrap as well.
Ultimately what will happen is that instead of taking a bootstrap-files, stdenv/linux/default.nix as an argument, it will instead take any stdenv as an argument. That argument can then be any of these:
- an unpacked
bootstrap-files (which has the same approximate shape as stdenv)
pkgsBuildBuild.stdenv
pkgsCross.${targetPlatform}.freshBootstrapFiles, providing a simple and straightforward way to say "rebuild the bootstrap-files and then use them to bootstrap" (useful for testing)
- the minimal-bootstrap end product
pkgsCross.${firstPlatform}.pkgsCross.${secondPlatform}.pkgsBuildTarget.stdenv, allowing to chain together cross compilations
- this is useful with the minimal-bootstrap, since that only supports 32-bit x86.
There is a huge amount of duplication between the cross bootstrap and
stdenv/linux. Both of them go through the same dance. The goal is to deduplicate this dance with no loss of functionality.Here is what the cross bootstrap looks like:
pkgsBuildBuild.stdenvpkgsBuildBuild.stdenvto compile the bintools (bintoolsNoLibc)pkgsBuildBuild.stdenvto compile a bare-bones compiler (gccWithoutTargetLibc/clangNoLibc)Here are the native linux stages:
bootstrap-filesbootstrap-filescompiler+bintools to compile the bintoolsbootstrap-filescompiler and new bintools to the bare-bones compiler (xgcc)The only native bootstrap step that doesn't correspond to anything in the cross bootstrap is the very last one. It exists only because the native bootstrap has a
disallowedReferencesentry for thebootstrap-files, but cross bootstrap doesn't care about that. This stage would simply be skipped in the cross case. Or we could keep it and add thedisallowedReferencescheck to the cross bootstrap as well.Ultimately what will happen is that instead of taking a
bootstrap-files,stdenv/linux/default.nixas an argument, it will instead take anystdenvas an argument. That argument can then be any of these:bootstrap-files(which has the same approximate shape asstdenv)pkgsBuildBuild.stdenvpkgsCross.${targetPlatform}.freshBootstrapFiles, providing a simple and straightforward way to say "rebuild thebootstrap-filesand then use them to bootstrap" (useful for testing)pkgsCross.${firstPlatform}.pkgsCross.${secondPlatform}.pkgsBuildTarget.stdenv, allowing to chain together cross compilations