Since the tool is exposed more prominently now, we should clear up what
it is and note that it is to be considered unstable, i.e. we may change
it if the necessity arises. (In practice it is probably going to be
fairly stable though, as compiler interfaces tend to be quite stable.)
Should we add a version?
The cc and bintools wrapper contained ad hoc bootstrapping logic for
expand-response-params (which was callPackage-ed in a let binding). This
lead to the strange situation that the bootstrapping logic related to
expand-response-params is split between the wrapper derivations (where
it is duplicated) and the actual stdenv bootstrapping.
To clean this up, the wrappers simply should take expand-response-params
as an ordinary input: They need an adjacent expand-response-params (i.e.
one that runs on their host platform), but don't care about the how.
Providing this is only problematic during stdenv bootstrapping where we
have to pull it from the previous stage at times.
We don't need to artificially make sure that we can execute the wrapper
scripts on the build platform by using stdenv's shell (which comes from
buildPackages) since our cross infrastructure will get us the wrapper
from buildPackages. The upside of this change is that cross-compiled
wrappers (e.g. pkgsCross.aarch64-multiplatform.gcc) will actually work
when executed!
For bootstrapping this is also not a problem, since we have a long
build->build platform chain so runtimeShell is just as good as
stdenvNoCC.shell. We do fall back to old ways, though, by explicitly
using the bootstrap-tools shell in stage2, so the adjacent bash is only
used from stage4 onwards. This is unnecessary in principle (I'll try
removing this hack in the future), but ensures this change causes zero
rebuilds.
To reduce dependencies (mainly nix-prefetch-git and through that git,
git-lfs) when we just need to fixup a lock file, eg when building electron.
This also tries to avoid needless rebuilds when eg. golang is updated.
Also this cleans up and combined the build/installPhase of both tools to
be a lot simpler.
In delicate code like this, it seems unwise to pass something of as
something it isn't for convenience's (?) sake. It causes a slight
possibility for confusion with `buildPackages.stdenv`. However, it
should be possible to eliminate the need for this in a separate change.
`stdenv.is*` defaults to `hostPlatform` which is technically incorrect
here, since what we are gating concerns the target platform only.
This would be a problem in practice if cross compiling from
x86_64-darwin to aarch64-darwin whilst using gcc which is probably
rare enough.
Replace `src = ./.` instances with more explicit source listings.
Otherwise, derivations will be rebuilt on any change to the files
defining them (e.g. formatting via nixfmt-rfc-style).
After enabling a separate binary output for the `Agda` Haskell package,
the new `bin` output measures ~100MiB, compared to the ~4.5GiB before.
Using it in `agdaWithPackages` reduces the closure size of an Agda
installation from ~5GiB to ~3GiB. The remaining space is taken up
mostly by the GHC backend.
With this change, derivations depending on `haskellPackages.Agda`
directly need to pick the right (binary) output. This concerns in
particular `emacsPackages.agda2-mode`.
`lib.getExe pkgsCross.riscv64.buildPackages.pkg-config` should return
`<prefix>/bin/riscv64-unknown-linux-gnu-pkg-config` not `<prefix>/bin/pkg-config`
This was added in d83e9c9573,
but included substitution variables `@blas@` and `@lapack@` that were
never substituted. It's not used anywhere in `nixpkgs`.
Ignore vendorSha256 when vendorHash is specified.
Throw when vendorHash isn't specified:
- "buildGoModule: Expect vendorHash instead of vendorSha256" when
vendorSha256 is specified.
- "buildGoModule: vendorHash is missing" otherwise.
`goModules.outputHashAlgo` is specified as null when vendorHash is not
empty, "sha256" otherwise.
Co-authored-by: zowoq <59103226+zowoq@users.noreply.github.com>
