This change only consolidates the logic for the source built GHCs which
have used the same logic (at least as long as you'd only use the
respective supported version ranges of the expressions as inputs).
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
```
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Conflicts:
pkgs/by-name/ba/bacon/package.nix
pkgs/by-name/be/beancount-language-server/package.nix
pkgs/by-name/fl/flake-edit/package.nix
pkgs/by-name/fw/fw/package.nix
pkgs/by-name/im/impression/package.nix
pkgs/by-name/in/inori/package.nix
pkgs/by-name/pi/pika-backup/package.nix
pkgs/by-name/ri/rip2/package.nix
pkgs/by-name/sn/sniffnet/package.nix
pkgs/by-name/sy/syndicate_utils/package.nix
pkgs/development/tools/misc/texlab/default.nix
In the cases where an update collided with cargoHash change,
I took the hash from the update.
Breaks Darwin bootstrap:
CMake Error at /tmp/nix-build-llvm-tblgen-19.1.7.drv-0/llvm-tblgen-src-19.1.7/lldb/test/CMakeLists.txt:197 (message):
LLDB test suite requires libc++, but it is currently disabled. Please add
`libcxx` to `LLVM_ENABLE_RUNTIMES` or disable tests via
`LLDB_INCLUDE_TESTS=OFF`.
It’s probably not too hard to fix but I don’t really understand the
details of this derivation and it’s blocking Darwin `stdenv` builds
with a few days to go until the next cycle, so reverting for now.
This reverts commit d175d8a4c5.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
