This allows multi-output derivations using e.g. `buildPackage` to work.
Without this change, they fail to build because Nix thinks
`buildDepsOnly` is supposed to produce mulitple outputs too, but it
doesn't.
---------
Co-authored-by: Ivan Petkov <ivanppetkov@gmail.com>
This makes it possible to evaluate crane in a nixos test without network
as well as allow to backup all fetched input derivations properly in a
binary cache, whereas fetchGit will fallback to downloading from a
repository, which also requires a `git` binary to be present.
Co-authored-by: Ivan Petkov <ivanppetkov@gmail.com>
* mkDummySrc: also include `no_std` attrs for target_os = uefi
* buildDepsOnly: only check with `--all-targets` if doCheck enabled
* mkDummySrc: allow customizing dummy Rust file contents
* This allows for fewer assumptions about the project structure
* The old behavior can easily be brought back by setting `cargoExtraArgs
= "--workspace";` in any derivation
* Previously we would manually copy over any Cargo.lock file from the
source to the dummified source
* Now, `mkDummySrc` will implicitly copy the file if it is present, or
ignore it if missing, so this check is a bit overzealous now
* Loosening this check also allows callers to sneak in their own
Cargo.lock file (e.g. through a patch phase) while still avoiding IFD
* Seems like Nix can get unhappy if a path fragment is evaluated too
eagerly, giving errors like
`error: access to absolute path '/Cargo.toml' is forbidden in pure eval mode (use '--impure' to override)`
* Changing to using string manipulation seems to resolve the issue
* Similarly rename `installCargoTargetDirHook` to
`installCargoArtifactsHook`
* The intention is to highlight that "install" implies "copy to output"
and not anywhere else
* Also avoids the potential confusion of "cargo target dir" (location of
cargo's artifacts) with "cargo target" (which is the target
architecture/platform we want cargo to build for)
* By default we pass everything through to the actual derivation itself,
but some internal parameters don't show up as environment variables
directly (or rather do not need to)
* In an effort to keep the build environment as lean as possible, we can
do some clean up (e.g. to avoid invalidating builds if some parameter
changes but is completely ignored/overridden elsewhere)
* This hook was never a great implementation to begin with since it
would simply search the cargo artifacts directory for binaries and
libraries to install
* This isn't really great since if we have multiple builds (say one with
debug artifacts, one with release artifacts) it isn't exactly clear
which artifacts would get installed (or which will get clobbered).
* Now that we have installFromCargoBuildLogHook we can simplify the
options a bit and only have one main installation method. The caller
can always provide their own if they wish
* The intention here is to split up different "responsibilities" into
smaller parts which can be composed as a DAG rather than mutually
recursive functions. Specifically:
* `mkCargoDerivation` represents a lower-level thin wrapper around
`stdenv.mkDerivation` which will
- set up hooks
- require the caller to define the variables needed by the hooks (like
vendor dir, or artifacts to inherit)
- ensure that build/check/install phases can be configured by the
caller without having them remember to call pre/post hooks
* This allows `buildDepsOnly` to only focus on setting some default
values (like good default commands to build all artifacts, setting the
derivation name, etc.) and delegating the rest to `mkCargoDerivation`
* Lastly, the responsibility of `buildWithCargo` ends up ensuring that
`cargoArtifacts` and `cargoVendorDir` are defined if the caller does
not pass them in
