-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
meson: add Rust cross support #159064
meson: add Rust cross support #159064
Conversation
else if isx86_64 then "x86_64" | ||
else parsed.cpu.family + builtins.toString parsed.cpu.bits; | ||
|
||
crossFile = if stdenv.hostPlatform == stdenv.targetPlatform then null else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cannot really comment much about this other than that the cross file was in Meson expression in the past. Not sure, what the reasons were for the move. cc @Ericson2314
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah putting it in stdenv
is gross, but i think it is better so that we avoid a target-sensative meson.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@matthewbauer and I did this, and opened up an issue for "nix setup hooks", so that we could have some modularity without trying to do this stuff in bash instead of Nix
Also, I see how I factored this stuff out in https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/rust/lib/default.nix so we don't need to refer to a specific version of rustc. CC @dcbaker is there something we can do better than just sneaking in a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So just to be clear, rather keep in stdenv until we have a better solution. mesonPackge
or cmakePackage
functions would be fine with me!
No better way than to slip —target in somewhere. Ideas welcome for a better way |
@Ericson2314 I really want to avoid any more build-system specific builder functions, because they don't compose, and make it difficult to handle packages with multiple build systems. ( What's the problem with a target-sensitive Meson? It's tiny and builds in seconds. |
I hear you, but setup hooks are really frighteningly complex / "false modularity" to me, and I would like to move away from them and bash shenanigans in general. I would appreciate if we could just fix this issue in the current style, and then discuss what to do for Meson and CMake, doing whatever we choose consistently for both of them. |
The reason I changed it was that the |
Yeah! I pulled out https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/rust/lib/default.nix, analogous to the Haskell lib. I suppose we should import it somewhere accessible from the top-level, and use it. (More broadly, It would be nice to establish some clearer conventions around language infra. E.g. some Haskell stuff should probably move to |
Keep language-specific infrastructure next to language-specific folders. If a tool is overly lang-specific, it is more discoverable inside the lang, not outside of it. |
Well I just want us to be consistent :). I personally like distinguishing Haskell/Cabal support from Hackage, Rust/Cargo from Crates.io, etc. etc. but it's not important I'll go with the flow |
Stack/Cabal are rarely used outside Haskell. No one would download a truckload GHC just to compile a C library that otherwise can be build with Autotools or Meson. |
Yes, but people might do Haskell without Hackage, or Rust without crates.io. That's the distinction I was making. |
python310Packages.pontos: 23.5.0 -> 23.5.1
httpx: 1.3.0 -> 1.3.1
python310Packages.sonos-websocket: 0.1.0 -> 0.1.1
python310Packages.pytrafikverket: 0.3.1 -> 0.3.3
python310Packages.angr: 9.2.49 -> 9.2.50
libfsm: 0.1pre2442 -> 0.1pre2987
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 gets rid of the "rust" attribute, which can confuse users expecting that to refer to a package. - 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.
Motivation for this change
See commit messages.
Things done
sandbox = true
set 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/
)nixos/doc/manual/md-to-db.sh
to update generated release notes