* feat: add cargoLlvmCov
* cargoHelperFunctionsHook: prefer `--release` over `--profile release`
Some tools (e.g. cargo-llvm-cov) don't understand `--profile release` as
an alias for `--release`, so `cargoWithProfile` should prefer passing
`--release` when `$CARGO_PROFILE` == "release"
---------
Co-authored-by: Ivan Petkov <ivanppetkov@gmail.com>
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.
* Previously all build hooks were instantiated in a single
`callPackages` call which led to several issues:
- changes via `lib.overrideScope'` were ignored because the build
hooks were only ever instantiated with the nixpkgs instance of our
flake (not whatever overlays the caller may have made)
- the pkgs splicing was not done quite right, meaning when we pull in
the build hooks as nativeBuildInputs the splicing wasn't picking up
the overridden versions of `cargo` but was instead trying to
recompile the nixpkgs version each time
* Rather than recursively look up all paths in a given project and then
filtering for cargo-specific files, we now use our own customized
traversal method to only capture the results we want.
* 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
