In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
Seeing the following new warnings pop up on stderr when cargo was bumped
to 1.78:
```
warning: `/build/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
```
which happens to break commitmsgfmt builds in nix (#320294).
closes#320294
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
I broke the usage of buildRustCrate with a toolchain from rust-overlay
when I added support for wasm32-unknown-unknown, this change adds
additional conditionals to restore the usage.
The toolchain can now be overriden either through
```
buildRustCrate {
rust = toolchain;
cargo = toolchain
}
```
or
```
buildRustCrate.override {
rustc = toolchain;
cargo = toolchain;
}
```
They should now be consistent with each other.
Previously, it wasn't possible to access the list of platforms we can
build Rust programs for outside of buildRustPackage. This was a
problem for packages that have optional Rust components, like
gstreamer or Meson, as there was no way to only build the Rust parts
for supported platforms. Now it's possible to get that information
from rustc's passthru.
We should constrain the set of supported platforms to the platforms
supported by the compiler. Otherwise we run into the unfortunate
situation where setting meta.platforms in a Rust package to
platforms.unix or platforms.linux will reintroduce CPU architectures
unsupported by the compiler.
Currently we cannot debug rust binaries on darwin (via lldb).
The debug symbols seem to be provided by default in a number of files
in `target/debug/deps/*.rcgu.o`. As far as I can tell these have
hardcoded paths referring to the ephemeral build directory. However,
`split-debuginfo=packed` conveniently produces a `.dSYM` file that can
be copied to `$out/bin/` and immediately provide debugging information.
Fixes https://github.com/NixOS/nixpkgs/issues/262131
Since version 2.0.0, proc-macro-crate has assumed it can exec()
`env::var("CARGO")` in order to run `cargo locate-project`.
This commit adds a crate override to proc-macro-crate which simply writes the
path to buildPlatform.cargo into the proc-macro-crate sources.
This way we don't need to set `env.CARGO` for every build that depends on
proc-macro-crate -- if we do that, the $CARGO environment variable would be
visible to the entire build. This could potentially lead to incredibly
hard-to-troubleshoot heisenbugs if there is some other crate that expects
`env::var("CARGO")` to exist -- that other crate would mysteriously work only
in projects that use proc-macro-crate but not anywhere else!
This is executed curing the build, and usually quite helpful in telling
you how the build failed, if it failed.
For example, when linking against system libraries, it shows which
system lib could not be discovered, the pkg-config path used etc.
Not showing it simply removes all this, and trying to parse out the
"important" bits and only show these is probably also brittle.
The output generally isn't that spammy normally, so let's just `tee` it.
Added a cross compilation test for wasm32-unknown-unknown. This also
required using crate.metadata instead of using the regex to get rid of
the hash in the library filename. It also required adding a mkCrate
argument to assertOutputs so we can override the buildRustCrate used.
With this change you will finally be able to use
buildRustCrate/crate2nix to build your wasm32-unknown-unknown
rust projects.
Simply import nixpkgs like so:
```
lib = <nixpkgs/lib>;
pkgsForWasm32 = import <nixpkgs> {
crossSystem = lib.examples.wasm32-unknown-none;
}
```
or use pkgsCross directly with
```
pkgsCross.wasm32-unknown-none.callPackage ./. { };
```
In order to allow for the new `cargo::` prefix for build script outputs
we have to adjust the configure-crate bash scripts in buildRustCrate to
properly parse the new additional syntax.
These changes don't affect existing build scripts configured with the
old `cargo:` prefix.
For more information, see https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script
When cross compiling proc macros, the proc macro needs to be built for the
build platform's architecture.
Without this change cross compiling from Darwin to Linux would simply
fail because it tries to link to a library with a file extension that
doesn't exist on the builder's platform.
