This commit adds the machinery required to get our `rustc.nix` to
work using upstream's git repository, directly, without them waving
dead chickens over it and performing whatever other occult rituals
are involved in creating a release tarball.
No chickens, live or dead, were harmed in the creation of this
commit.
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.
This upgrade unfortunately removes MIPS support, as it has been
dropped to Tier 3[1] and so bootstrap tarballs are no longer provided.
It looks like it was dropped due to multiple codegen bugs, and lack of
maintenance, so bringing it back would probably involve engaging with
Rust/LLVM upstream on those.
[1]: https://github.com/rust-lang/compiler-team/issues/648
The hash for pytensor is not correct, but that's also the case in
master, so a merge commit isn't the place to fix it.
Conflicts:
pkgs/development/python-modules/faadelays/default.nix
pkgs/development/python-modules/pytensor/default.nix
pkgs/tools/admin/rset/default.nix
When cross-compiling a rust package, all we need is the std library compiled
for the target. This uses the final stage compiler which was built for Build
and then uses that as a stage0 compiler for target std library.
It also copies the rust binary from pkgsBuildBuild so that it find the new
lib/rustlib directory.
We also need to create a cargo wrapper which will use the "new" rust compiler
Also makes sure man pages and doc pages are propagated
Co-authored-by: Alyssa Ross <hi@alyssa.is>
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Co-authored-by: Rick van Schijndel <Mindavi@users.noreply.github.com>
Recent changes to `cargo-auditable-cargo-wrapper` and `librsvg`
caused it to ignore the user's decision to opt out of `cargo-audit`
functionality, partially because `librsvg` does not use
`buildRustPackage`.
This commit restores the single-point-of-opt-out from this mis-named
functionality: `cargo-auditable.meta.broken`.
Co-authored-by: figsoda <figsoda@pm.me>
An attempt to remove it was made in #106886, but there was a build
failure. Since that failure no longer occurs, remove it now.
Based on thefloweringash/nixpkgs@1904236648.
armv6l-linux was incorrectly added to the list of platforms without host
tools in #227987. arm-unknown-linux-gnueabihf is present in the list of
Tier 2 targets with host tools, and this target corresponds to our
armv6l-linux platform.
Reading this [rust-issue] it seems that we have to link against
rustc_driver. The [clippy.nix] expression already does something similar
Of the 4 executables found in the result of building rustfmt only
rustfmt and git-rustfmt needed to be linked. The other worked without
linking to rustc_driver.
[rust-issue]: https://github.com/rust-lang/rust/pull/105609
[clippy.nix]: c8cf570dae/pkgs/development/compilers/rust/clippy.nix (L27-L36)
It is almost never correct to use these attributes, because they don't
work correctly with splicing. Compare:
% nix repl -f . --argstr crossSystem aarch64-linux
Welcome to Nix 2.10.3. Type :? for help.
Loading installable ''...
Added 18988 variables.
nix-repl> callPackage ({ stdenv, rustc }: (stdenv.mkDerivation { name = ""; nativeBuildInputs = [ rustc ]; }).nativeBuildInputs) {}
«derivation /nix/store/bjrkg8kcq3hvg5kb03ivb856zy91qpbk-aarch64-unknown-linux-gnu-rustc-1.69.0.drv» ]
nix-repl> callPackage ({ stdenv, rustPlatform }: (stdenv.mkDerivation { name = ""; nativeBuildInputs = [ rustPlatform.rust.rustc ]; }).nativeBuildInputs) {}
«derivation /nix/store/ra5r07j52y7akclr827r3dzxzvqnvfbl-rustc-1.69.0.drv» ]
I'm not sure this is fixable. I don't think it's worth keeping them
around considering we have top level attributes. It makes overriding
slightly more annoying, but only slightly.
I made a mistake when trying to add the target prefix to Rust cross
compilers: pkgsCross.aarch64-multiplatform.rustc ended up being called
"aarch64-unknown-linux-gnu-rustc-aarch64-unknown-linux-gnu-1.69.0",
which is a bit verbose.
With this change:
nix-repl> rustc.name
"rustc-1.69.0"
nix-repl> pkgsCross.aarch64-multiplatform.buildPackages.rustc.name
"aarch64-unknown-linux-gnu-rustc-1.69.0"
nix-repl> pkgsCross.aarch64-multiplatform.rustc.name
"rustc-aarch64-unknown-linux-gnu-1.69.0"
As intended.
Fixes: 57e73d23bb ("rustc,rustPlatform.buildRustPackage: broaden platforms")
rustc supports way more platforms than Linux and Darwin. We might not
be able to build it for every platform at the moment, but that's what
meta.broken is for.
There are other platforms that rustc can produce binaries for, but
can't run on itself, so those are listed in the defaults for
buildRustPackage.
Prior to this commit, builds of
`pkgsCross.aarch64-multiplatform.cargo` would fail due to being
unable to find `-lz` when compiling cargo's own `build.rs` for the
`buildPlatform`.
This environment variable uses the (very confusing) LLVM convention
of calling the buildPlatform "HOST".
Co-authored-by: figsoda <figsoda@pm.me>
