Conversation
There was a problem hiding this comment.
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.
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.
@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 |
Ericson2314
left a comment
There was a problem hiding this comment.
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 = 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/)nixos/doc/manual/md-to-db.shto update generated release notes