mesa: fix cross compilation to x86_64 - #233628
Conversation
alyssais
added
6.topic: rust
github-actions
Bot
added
6.topic: GNOME
This comment was marked as resolved.
This comment was marked as resolved.
|
@ofborg eval |
c58048e to
5f13c40
Compare
ofborg
Bot
added
10.rebuild-darwin: 501+
This comment was marked as outdated.
This comment was marked as outdated.
5762742 to
c0d3cbb
Compare
|
I've rebased to fix the merge conflict, and I've also:
All suggested by @Ericson2314. |
ghost
left a comment
ghost
left a comment
There was a problem hiding this comment.
We need lib.warn backwards-compatibility placeholders on the toFooBar attributes; crate2nix uses them (in their current location).
Otherwise looks good.
Building:
- pkgs.tests.cross.sanity
ofborg
Bot
removed
the
2.status: merge conflict
main issue fixed; will approve once builds complete
ghost
mentioned this pull request
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.
In particular, fix cross compilation of rusticl.
|
I agree, this should be merged before the branch-off. However,
I think that ship has sailed 😆 unless |
|
The sphinx build failure on x86_64-linux seems to be intermittent / load-related. Let's try again: @ofborg build mesa mesa.passthru.tests stdenv stdenv.passthru.tests |
I've been getting (and I don't think it is caused by this PR) We should consider disabling the tests for the |
|
OfBorg hasn't given me the aarch64 builds for days, so I'm just going to merge. I've tested locally on x86_64-linux and aarch64-linux, and IIRC mesa is broken on Darwin anyway. In the unlikely event there are failures, we'll catch them in staging. |
|
Seems like this PR broke all packages that use |
|
Nevermind, I found #267876 which should fix this. |
|
Fix is #268168. |
8 participants
Description of changes
In particular, fix cross compilation of rusticl. Previously, Nixpkgs has not been equipped to handle non-Cargo Rust cross compilation. That's getting increasingly important, now that we're building Mesa with Rust, and soon the kernel, and potentially systemd in not too long.
This is a bigger PR than I usually like to make, but it's difficult to explain each of these changes out of context, so I've bundled them into a single PR. I'd definitely recommend reviewing commit by commit though. The commit messages contain the details of each change.
Spiritual successor to #159064.
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)