We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
The updated Darwin stdenv uses `llvm-strip`, but that causes issues for
rav1e when using NASM and linking it with the cctools ld64. Stripping
the debug information instead of everything fixes the problem.
`cargo cbuild` needs to have the `C{C,XX}_FOR_{${platform}}`
variables set just like `cargo` since it is basically a wrapper
around cargo. Without these variables, it will try to use the
`hostPlatform` C compiler to compile `build.rs` scripts, and will
pass flags to that compiler which only make sense on the
`buildPlatform`. So it's just doomed without the environment
variables.
Right now it looks like `rav1e` is the only package we have that is
using `cargo-c`, but if that changes in the future we should factor
this out as its own hook, like `maturinBuildHook` and the others.
This is a native build input because it's used at build time by the
"built" crate, which tries to embed git info and build timestamps into
the binary (ugh).
This fixes cross-compilation from x86_64 to aarch64, because git2's
build.rs tries to use -m64, which is x86_64-only.
Rust 1.50.0 incorporated a Cargo change (rust-lang/cargo#8937) in
which cargo vendor erroneously changed permissions of vendored
crates. This was fixed in Rust
1.51.0 (rust-lang/cargo#9131). Unfortunately, this means that all
cargoSha256/cargoHashes produced during the Rust 1.50.0 cycle are
potentially broken.
This change updates cargoSha256/cargoHash tree-wide.
Fixes#121994.
The Cargo.lock file is not included in the master branch but it is
currently added for the releases (e.g. [0]). Since the GitHub deploy
action currently fails for other reasons [1] we should use the
Cargo.lock from the repository instead.
[0]: 80573d2bf7
[1]: https://github.com/xiph/rav1e/issues/2373
Changes the default fetcher in the Rust Platform to be the newer
`fetchCargoTarball`, and changes every application using the current default to
instead opt out.
This commit does not change any hashes or cause any rebuilds. Once integrated,
we will start deleting the opt-outs and recomputing hashes.
See #79975 for details.
