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.
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.
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.
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
Switched to a common attribute for library file extensions:
de70971c90
This makes buildRustCrate evaluate successfully when using
pkgsCross/pkgsStatic.
--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.
This fixes at least one bug with default-features, and also
just aligns us more with what Cargo actually does.
Also some Python style fixes and a bit less mutating state.
Replace `src = ./.` instances with more explicit source listings.
Otherwise, derivations will be rebuilt on any change to the files
defining them (e.g. formatting via nixfmt-rfc-style).
We need to set -crt-static on musl for rustdoc as well, so let's unify
the wrappers. Ideally, rather than wrapping rustdoc, we'd have
rustdoc use the wrapped rustc, but that's currently only possible with
an unstable option (--test-builder).
The options set by the wrapper, -C target-feature and --sysroot, are
supported by both rustdoc and rustc, but other flags maybe not be
supported by both, so I've introduced different environment
variables (the existing NIX_RUSTFLAGS and a new NIX_RUSTDOCFLAGS) to
allow those to be set independently.
This fixes cargo-auditable in pkgsMusl., which broke because its
doctests stopped working when -crt-static was moved to the wrapper.
Fixes: 79156bf13a ("rustc: move crt-static default override to wrapper (#291829)")
Previously, when cross compiling from non-musl to musl, the crt-static
default override wouldn't be applied, because the compiler wouldn't
have been built with it due to fastCross. Moving it to the wrapper
fixes this without having to introduce extra compiler rebuilds. And
because the wrapper is applied even to the bootstrap rustc, we no
longer need special handling of crt-static in the Cargo expression.
Unlike --sysroot, rustc allows -C target-feature= to be passed
multiple times, with later instances taking precedence over earlier
ones. This means that it's very easy to set the default in the
wrapper, just by our overridden default before any other arguments.
This fixes pkgsCross.aarch64-multiplatform-musl.mesa from x86_64-linux.
