* Source vendoring is passed as a standalone attribute to
`mkCargoDerivation`, meaning it does not automagically get spliced
with the correct local/cross system inputs (i.e. what would happen if
it was a `depsBuildBuild` entry)
* To fix this we need to make sure that `vendorCargoDeps` and all of its
transitive dependencies always use `runCommand` (and friends) from
their `pkgsBuildBuild` equivalent. This should always be safe to do
(even for cross-builds) since this amounts to building up a bunch of
sources which will be read by the build system
* Unfortunately I had to manually specify `pkgsBuildBuild.whatever` in
multiple places as I could not get things to work by messing with the
`callPackage` definition. Perhaps we should be using
`makeScopeWithSplicing'` instead of `makeScope` when constructing the
library, but I couldn't get it working (and I couldn't find any decent
docs on how to use it online) so this will make do for the time being.
* This should hopefully result in fewer surprises if someone is using a
really ancient toolchain for their code since we'll use whatever is in
nixpkgs to build craneUtils instead
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 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
* 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
* 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)
* 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
* Copying the cargo artifacts to their own separate output is a good
idea *in theory* where each derivation produces bins/libs so that
other things can depend on them without pulling in the cargo artifacts
as well
* In practice, it's much more likely that a derivation will produce
cargo artifacts (to be reused in other build/test steps) XOR produce
the final binaries
* Therefore _not_ separating the outputs will produce less friction when
forming dependency trees in the general path (e.g. no more forgetting
to specify `drv.target`)
* If a caller really wants to install cargo artifacts in a separate
output, they can easily add the customization themselves
* Hook functions now will accept any relevant arguments and fall back to
our default variables if they are not provided, potentially allowing
them to be adapted externally (without needing more configuration
knobs on our end)
* Reducing the parameter surface area for good measure, zstd compression
works pretty well and it seems redundant to support multiple ways of
copying the target directory around
* Instead of always installing the hook but bailing early based on the
configuration, we will instead only install the hook if the
configuration requests it
* Hopefully the updated name should be more clear that we are inhering
some existing cargo artifacts and NOT inheriting something like
CARGO_BUILD_TARGET which refers to the host target being built
* This allows us to copy over the cargo artifacts as early as possible
so that any other phases/hooks (like running clippy) can take
advantage of the cache
* It also avoids installing the artifacts too soon (and making them
older than the source) and having cargo invalidate them
* Rather than clobbering the project's .cargo/config.toml file (if it
exists), the setup hook will update the base configuration used in
$CARGO_HOME/config.toml
* This potentially allows for projects who know what they are doing to
more easily replace their own sources, while falling back to our
configuration
* This will define CARGO_HOME to $PWD/.cargo-home to ensure that cargo
never tries to look for a missing HOME directory as it's default
location
* The hook is also added to `postPatchHooks` (instead of
`preConfigureHooks`) to ensure that it runs before all other
configuration-related hooks
* The intention is to make it more clear that this flag controls copying
the target directory so that *other* derivations can use it, and DOES
NOT control whether we use an *existing* target directory from another
derivation
* If the source root contains a Cargo.lock file it will be used to
create a vendor directory
* Otherwise a (descriptive) error will be thrown describing how to
remediate
* The caller can, of course, manually specify their own `cargoVendorDir`
which will skip the default vendoring
* We can simplify the configuration by removing the
`doCopyTargetToSeparateOutput` parameter
* If a caller wants to copy target artifacts into any other output, it
is pretty trivial for them to add their own logic for it
