Skip to content
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

Closed
wants to merge 90 commits into from
Closed

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.

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
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 reputable 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 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 6.topic: ocaml 6.topic: python 6.topic: qt/kde 6.topic: rust 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 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 6.topic: ocaml 6.topic: python 6.topic: qt/kde 6.topic: rust 6.topic: stdenv Standard environment 10.rebuild-darwin: 501+ 10.rebuild-darwin: 5001+ 10.rebuild-linux: 501+ 10.rebuild-linux: 5001+ 12.approvals: 1 This PR was reviewed and approved by one reputable person
Projects
None yet
Development

Successfully merging this pull request may close these issues.