Skip to content

meson: add Rust cross support#159064

Closed
alyssais wants to merge 90 commits intoNixOS:stagingfrom
alyssais:meson-rust
Closed

meson: add Rust cross support#159064
alyssais wants to merge 90 commits intoNixOS:stagingfrom
alyssais:meson-rust

Conversation

@alyssais
Copy link
Member

Motivation for this change

See commit messages.

Things done
  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 22.05 Release Notes (or backporting 21.11 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
    • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
  • Fits CONTRIBUTING.md.

@alyssais alyssais added 6.topic: cross-compilation Building packages on a different platform than they will be used on 6.topic: rust General-purpose programming language emphasizing performance, type safety, and concurrency. labels Feb 10, 2022
@github-actions github-actions bot added 6.topic: stdenv Standard environment and removed 6.topic: rust General-purpose programming language emphasizing performance, type safety, and concurrency. labels Feb 10, 2022
@ofborg ofborg bot requested review from AndersonTorres and jtojnar February 10, 2022 23:24
@ofborg ofborg bot added 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. labels Feb 10, 2022
Copy link
Member

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

Copy link
Member

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.

Copy link
Member

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

@Ericson2314
Copy link
Member

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 --target ... flag? It would be great if we could embed the target platform json in the cross file more declarative. c.f. how the Nix platform description includes it.

Copy link
Member

@Ericson2314 Ericson2314 left a 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!

@dcbaker
Copy link
Contributor

dcbaker commented Feb 21, 2022

No better way than to slip —target in somewhere. Ideas welcome for a better way

@alyssais
Copy link
Member Author

@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. (buildRustPackage is a prime example of this and I'd really like to be rid of it one day.)

What's the problem with a target-sensitive Meson? It's tiny and builds in seconds.

@Ericson2314
Copy link
Member

Ericson2314 commented Feb 22, 2022

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.

@alyssais
Copy link
Member Author

The reason I changed it was that the rust functions were inaccessible in make-derivation.nix. Are you saying there's a way to use them there?

@Ericson2314
Copy link
Member

Ericson2314 commented Feb 22, 2022

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 pkgs/build-support and the two language libs should be named similarly.)

@AndersonTorres
Copy link
Member

(More broadly, It would be nice to establish some clearer conventions around language infra. E.g. some Haskell stuff should probably move to pkgs/build-support and the two language libs should be named similarly.)

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.

@Ericson2314
Copy link
Member

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

@AndersonTorres
Copy link
Member

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.

@Ericson2314
Copy link
Member

Yes, but people might do Haskell without Hackage, or Rust without crates.io. That's the distinction I was making.

@Artturin Artturin added the 12.approvals: 1 This PR was reviewed and approved by one person. label May 4, 2022
@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Nov 2, 2022
fabaff and others added 8 commits May 10, 2023 10:52
python310Packages.pontos: 23.5.0 -> 23.5.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.
@stale stale bot removed 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md labels May 10, 2023
@alyssais alyssais closed this May 10, 2023
@github-actions github-actions bot added 6.topic: GNOME GNOME desktop environment and its underlying platform 6.topic: lua Lua is a powerful, efficient, lightweight, embeddable scripting language. 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 6.topic: ocaml OCaml is a general-purpose, high-level, multi-paradigm programming language. 6.topic: python Python is a high-level, general-purpose programming language. 6.topic: qt/kde Object-oriented framework for GUI creation 6.topic: rust General-purpose programming language emphasizing performance, type safety, and concurrency. labels May 10, 2023
@alyssais alyssais deleted the meson-rust branch May 10, 2023 09:30
@NixOS NixOS locked and limited conversation to collaborators May 10, 2023
@alyssais alyssais restored the meson-rust branch May 10, 2023 09:33
@alyssais alyssais deleted the meson-rust branch June 23, 2023 10:54
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

6.topic: cross-compilation Building packages on a different platform than they will be used on 6.topic: GNOME GNOME desktop environment and its underlying platform 6.topic: lua Lua is a powerful, efficient, lightweight, embeddable scripting language. 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 6.topic: ocaml OCaml is a general-purpose, high-level, multi-paradigm programming language. 6.topic: python Python is a high-level, general-purpose programming language. 6.topic: qt/kde Object-oriented framework for GUI creation 6.topic: rust General-purpose programming language emphasizing performance, type safety, and concurrency. 6.topic: stdenv Standard environment 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. 12.approvals: 1 This PR was reviewed and approved by one person.

Projects

None yet

Development

Successfully merging this pull request may close these issues.