This fixes a long standing issue where rust hooks behave differently when used inside buildRustPackage vs inside mkDerivation, which lead to surprising behavior, like for example the package being built for the wrong paltform or the linker not being found especially in cross compilation scenarios.
The reason for this inconsitency was, that buildRustPackage consumed the hooks in a non-spliced form, via [this inherit statement](4506ece030/pkgs/development/compilers/rust/make-rust-platform.nix (L60)), and therefore the usual platform shift on the hooks introduced by putting them in `nativeBuildInputs` was not applied here.
Thoug whenever the hook was used inside other builders like `mkDerivation` the platform shift did apply correctly as the hook was consumed via the spliced package set, introducing the inconsitecy.
Because of the wrong (non-spliced) use in buildRustPackage, most rust hooks have been designed with the wrong build/host/target shift in mind which is fixed by this change.
Due to the inconsitent behavior between different builders, workarounds like `rust.envVars`, which were previously introduced, likely become obsolete by this change.
This likely fixes a bunch of cross compilation issues for rust packages that are not based on `buildRustPackage` but instead consume the hooks directly.
Done:
- ensure that `buildRustPackage` consumes spliced hooks by using makeScopeWithSplicing' in make-rust-platform.nix.
- refactor hooks to make them refer to correct build/host/target packages.
- remove `rust.envVars` workaround from all rust hooks
- implement tests for most rust hooks in /pkgs/test/rut-hooks
The newly added tests can be executed for native as well as cross compilation via:
```
nix-build -A tests.rust-hooks -A pkgsCross.riscv64.tests.rust-hooks
```
Tested the following packages with and without structuredAttrs:
- rust-analyzer: cargo-build-hook, cargo-check-hook
- jujutsu: cargo-nextest-hook
- kornia-rs: maturin-build-hook
--frozen is stricter than we need in Nixpkgs. If a Cargo.lock is
slightly wrong, or (in my use case) if building a subproject that is
not a member of the top-level workspace, but the correct Cargo.lock
can be entirely resolved from the existing top-level Cargo.lock, it
should be deterministic, and shouldn't cause any problems, to let
cargo generate the new Cargo.lock. This should result in less need to
bother upstreams about fixing their Cargo.lock files in cases where
they could have been automatically fixed.
Currently there is a state of severe confusion in
pkgs/build-support/rust/hooks/ regarding host vs target; right now
there is only "host" defined, but whether it means "host" or
"target" seems to fluctuate.
This commit corrects that, ensuring that all variables come in all
three flavors (build, host, target) and are used consistently with
the nixpkgs convention.
This also fixes the cross-compilation of packages which use
`maturinBuildHook` -- hooks go in `nativeBuildInputs` and are
phase-shifted backwards by one platform, so they need to be careful
about distinguishing between build and host.
Closes#247441
- API change: remove the `target` argument of `buildRustPackage`, the
target should always be in sync with the C/C++ compiler that is used.
- Gathering of binaries has moved from `buildPhase` to `installPhase`,
this simplifies the hook and orders this functionality logically
with the installation logic.
