2024-11-27 20:49:01 +01:00
|
|
|
{
|
|
|
|
lib,
|
|
|
|
buildPackages,
|
|
|
|
callPackages,
|
|
|
|
cargo-auditable,
|
|
|
|
config,
|
|
|
|
stdenv,
|
|
|
|
runCommand,
|
rust: fix splicing for rust hooks
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](https://github.com/NixOS/nixpkgs/blob/4506ece030a0c82d078edd0360ea8af6b4d94035/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
```
2025-01-01 02:40:34 +07:00
|
|
|
generateSplicesForMkScope,
|
|
|
|
makeScopeWithSplicing',
|
2024-11-27 20:49:01 +01:00
|
|
|
}@prev:
|
2020-10-01 17:51:46 -04:00
|
|
|
|
2023-01-12 12:22:07 -05:00
|
|
|
{
|
|
|
|
rustc,
|
|
|
|
cargo,
|
2023-04-13 10:12:52 -04:00
|
|
|
cargo-auditable ? prev.cargo-auditable,
|
2023-01-12 12:22:07 -05:00
|
|
|
stdenv ? prev.stdenv,
|
|
|
|
...
|
|
|
|
}:
|
2020-10-01 17:51:46 -04:00
|
|
|
|
rust: fix splicing for rust hooks
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](https://github.com/NixOS/nixpkgs/blob/4506ece030a0c82d078edd0360ea8af6b4d94035/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
```
2025-01-01 02:40:34 +07:00
|
|
|
(makeScopeWithSplicing' {
|
|
|
|
otherSplices = generateSplicesForMkScope "rustPlatform";
|
|
|
|
f =
|
|
|
|
self:
|
|
|
|
let
|
|
|
|
inherit (self) callPackage;
|
|
|
|
in
|
|
|
|
{
|
|
|
|
fetchCargoVendor = buildPackages.callPackage ../../../build-support/rust/fetch-cargo-vendor.nix {
|
|
|
|
inherit cargo;
|
|
|
|
};
|
2024-10-17 22:10:47 +02:00
|
|
|
|
rust: fix splicing for rust hooks
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](https://github.com/NixOS/nixpkgs/blob/4506ece030a0c82d078edd0360ea8af6b4d94035/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
```
2025-01-01 02:40:34 +07:00
|
|
|
buildRustPackage = callPackage ../../../build-support/rust/build-rust-package {
|
|
|
|
inherit
|
|
|
|
stdenv
|
|
|
|
rustc
|
|
|
|
cargo
|
|
|
|
cargo-auditable
|
|
|
|
;
|
|
|
|
};
|
2020-10-01 17:51:46 -04:00
|
|
|
|
rust: fix splicing for rust hooks
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](https://github.com/NixOS/nixpkgs/blob/4506ece030a0c82d078edd0360ea8af6b4d94035/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
```
2025-01-01 02:40:34 +07:00
|
|
|
importCargoLock = buildPackages.callPackage ../../../build-support/rust/import-cargo-lock.nix {
|
|
|
|
inherit cargo;
|
|
|
|
};
|
2021-05-08 07:40:34 +02:00
|
|
|
|
rust: fix splicing for rust hooks
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](https://github.com/NixOS/nixpkgs/blob/4506ece030a0c82d078edd0360ea8af6b4d94035/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
```
2025-01-01 02:40:34 +07:00
|
|
|
rustcSrc = callPackage ./rust-src.nix {
|
|
|
|
inherit runCommand rustc;
|
|
|
|
};
|
2020-11-07 00:31:25 +08:00
|
|
|
|
rust: fix splicing for rust hooks
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](https://github.com/NixOS/nixpkgs/blob/4506ece030a0c82d078edd0360ea8af6b4d94035/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
```
2025-01-01 02:40:34 +07:00
|
|
|
rustLibSrc = callPackage ./rust-lib-src.nix {
|
|
|
|
inherit runCommand rustc;
|
|
|
|
};
|
2021-02-09 11:38:25 +01:00
|
|
|
|
2025-06-25 01:18:58 +08:00
|
|
|
# Useful when rebuilding std
|
|
|
|
# e.g. when building wasm with wasm-pack
|
|
|
|
rustVendorSrc = callPackage ./rust-vendor-src.nix {
|
|
|
|
inherit runCommand rustc;
|
|
|
|
};
|
|
|
|
|
rust: fix splicing for rust hooks
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](https://github.com/NixOS/nixpkgs/blob/4506ece030a0c82d078edd0360ea8af6b4d94035/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
```
2025-01-01 02:40:34 +07:00
|
|
|
# Hooks
|
|
|
|
inherit
|
|
|
|
(callPackages ../../../build-support/rust/hooks {
|
|
|
|
inherit
|
|
|
|
stdenv
|
|
|
|
;
|
|
|
|
})
|
|
|
|
cargoBuildHook
|
|
|
|
cargoCheckHook
|
|
|
|
cargoInstallHook
|
|
|
|
cargoNextestHook
|
|
|
|
cargoSetupHook
|
|
|
|
maturinBuildHook
|
|
|
|
bindgenHook
|
|
|
|
;
|
|
|
|
};
|
|
|
|
})
|
2024-11-27 20:49:01 +01:00
|
|
|
// lib.optionalAttrs config.allowAliases {
|
|
|
|
rust = {
|
|
|
|
rustc = lib.warn "rustPlatform.rust.rustc is deprecated. Use rustc instead." rustc;
|
|
|
|
cargo = lib.warn "rustPlatform.rust.cargo is deprecated. Use cargo instead." cargo;
|
|
|
|
};
|
2025-03-27 18:43:02 +00:00
|
|
|
|
|
|
|
# Added in 25.05.
|
|
|
|
fetchCargoTarball = throw "`rustPlatform.fetchCargoTarball` has been removed in 25.05, use `rustPlatform.fetchCargoVendor` instead";
|
2020-10-01 17:51:46 -04:00
|
|
|
}
|