Crates from git repos are vendored in a flattened directory where each crate shows up at the root of the vendor directory. Since the vendoring step effectively breaks workspace structures, any crates which use workspace inheritance (e.g. package.version.workspace = true will fail to resolve.
To work around this we inspect the crate's workspace manifest (if it exists) and attempt to manually merge the values while copying the contents to the vendor directory.
Using `cp --no-preserve mode` ends up losing the executable bit of
previously compiled build scripts. Instead we should ignore the file
ownership, and subsequently make the files writable (since the store is
read only)
* When checking the original source for its name, make sure we throw
away the string context so we don't end up actually depending on the
original source instead of the cleaned one
* 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
* Turns out it is much faster to build up one big regex of the
references to remove and invoking `sed` just once than it is to invoke
it once per reference
For example, the Cargo git repo contains multiple "case" Cargo.toml
files in the testsuite. Let's ignore them like what Cargo does [1].
Co-authored-by: Ivan Petkov <ivanppetkov@gmail.com>
* Define a new installation mode which symlinks identical artifacts
against a directory of previously generated ones
* This allows for linear space usage in the Nix store across many
chained derivations (as opposed to using a zstd compressed tarball
which uses quadratic space across many chained derivations)
* This new installation mode is the new default for all cargo based
builds. The previous behavior is still available by setting
`installCargoArtifactsMode = "use-zstd";` on a derivation
* `buildPackage` will continue to use zstd compressed tarballs while
building dependencies (unless either of `cargoArtifacts` or
`installCargoArtifactsMode` is defined, in which case they will be
honored)
* Using substitutions for build hooks is a great way to ensure the
necessary utility is present without making the caller supply it to
the builder, except it makes things confusing when applying overrides
* For example, the `installFromCargoBuildLog` hook was inadvertently
ignoring any `cargo` overrides applied to the entire `lib`
instantiation
* By removing all explicit substations we also side step the issue of
trying to select the correct build/host/target version of the tool and
use whatever is present in the build environment
* Instead of injecting our own dummy `build.rs` file, we will patch the
`Cargo.toml` files to specify a build script in the Nix store
* This allow cargo to notice the difference (i.e. changed build script
path) where it could not before (due to nix enforcing that all sources
always have the same timestamp)
This is done to avoid breaking builds by including puts happen to have
setup-hooks which try to claim the configure phase (such as `cmake`).
The old behavior can be brought back by setting `configurePhase = null;`
on the derivation.
* Seems like cargo-audit only needs a `Cargo.lock` file and an advisory
database to run, so we can filter the inputs down even further to
avoid rebuilds and file copying into the Nix sandbox
