[RFC 0132] Meson Builds Nix

[AndersonTorres]

This RFC proposes to use Meson description files to deploy Nix.

Rendered!

[Ericson2314]

I would like to shepherd this. I would also recommend @edolstra and @thufschmitt.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/brainstorming-for-rfc-using-meson-to-build-nix-evaluator/21141/8

[p01arst0rm]

@AndersonTorres should add that the end goal is to have a nix be capable of building nix too? or is that out of the scope of the RFC

[AndersonTorres]

@AndersonTorres should add that the end goal is to have a nix be capable of building nix too? or is that out of the scope of the RFC

Self-hosting Nix is something that deserves its own soutenance de thèse. I will not pursue it here.

The references on "minimal bloat on the bootstrap route" are enough for now.

[edolstra]

This RFC is open for shepherd nominations!

[thufschmitt]

I don't have as much free time as I'd like to to actively take part in the design and implementation, but I'd like to shepherd this nonetheless

[davidak]

@AndersonTorres you can also add examples of projects that use Meson/Ninja, to show it's a viable option. I know GNOME and elementary OS uses it for it's ecosystem. Maybe we can also have a look specifically at similar tools that are highly portable and also ask them about their experience.

Is there evidence that this approach will achieve the goals stated?

[eli-schwartz]

@davidak https://mesonbuild.com/Users.html is an uncurated partial list of projects that use Meson, which you could browse through for examples.

e.g. the wayland ecosystem uses it across various projects, and xorg switched to it too.

[AndersonTorres]

@eli-schwartz can you talk something about multi-language support on Meson? I remember vaguely that Eelco sometimes make experimentations with Rust in the Nix source code.

[eli-schwartz]

@eli-schwartz can you talk something about multi-language support on Meson? I remember vaguely that Eelco sometimes make experimentations with Rust in the Nix source code.

Rust as a programming language is quite attached to the idea that the only way to use it is with the cargo program, no other build systems. It is of course possible to do, in any build system, the functional equivalent of Meson's custom_target('rust-prog', command: ['cargo', 'build']), with additional quirks to ensure that out of tree builds work. A number of Meson projects build rust executables with some sort of cargo-wrapper.py

Meson also supports rust as a first-class language:

executable('rust-prog',
    'foo.rs',
    'bar.rs',
)

You can also build shared or static libraries, and control their exact type with rust_crate_type: XXX (may be lib, staticlib/cdylib for a C ABI, rlib/dylib for a rust ABI).

Cargo is not involved -- Meson simply invokes rustc.

Meson does NOT support crates.io dependencies, although support for this is planned (it will most likely only work for projects without build.rs, which is fair because build.rs is evil).

AFAIK, Meson is probably the only build system that so much as tries to support anything other than "just run cargo".

[p01arst0rm]

theres no reasonable way to compile rust with meson due to its insistence of being tied to cargo. you /can/ build rust with meson using cargo currently if you do something like this:

cargo = find_program('cargo')

test= run_target(
    'test',
    command :
    [
        cargo, 'build',
        '--target-dir', meson.current_build_dir(),
        '--manifest-path', 'Cargo.toml')
    ])

and then setup the build definitions using a Cargo.toml file. this allows you to run meson compile test. for now, thats the neatest way i've found to compile rust with meson. iirc there are a bunch of people currently working on adding support for cargo subprojects, so it wont be an issue for long.

[eli-schwartz]

Assuming your definition of "reasonable" is "supports crate dependencies", that effectively sounds like exactly what I just said. :)

[p01arst0rm]

yeah.... supposedly when cargo subproject support is added, you could then build dependencies by building the subprojects within the meson project and importing them (the same way that one does with cmake). then define rust binaries/libraries while passing those targets as dependencies. this would allow you to use cargo to build the dependencies, but meson to build the main code.

[AndersonTorres]

As another curiousity: the same can be said about Zig?

[p01arst0rm]

from what i can tell, yes; though it seems zig support is futher along from googling around

[lheckemann]

This should also bring support for out-of-tree builds, I think? Which I'm quite keen on having.

[Ericson2314]

Hmm?

[FRidh]

This should also bring support for out-of-tree builds, I think? Which I'm quite keen on having.

Meson builds out of source only.

[eli-schwartz]

I imagine that @lheckemann's point is exactly as explicitly spelled out:

A desire to start using out of source builds, which the current Makefile definitely does not support.

[edolstra]

I accept the shepherd nomation.

This RFC is now under discussion with the following shepherds: @Ericson2314, @edolstra and @thufschmitt. @Ericson2314 Do you want to lead this one?

[Ericson2314]

@edolstra Sure!

[Ericson2314]

https://matrix.to/#/#nix-rfc-132:matrix.org

[Ericson2314]

Notes from the meeting today https://pad.lassul.us/s/nKZmODCnj# In particular these are the action items:

Action items

• Aim for next meeting early January

• Propose replacing build systems, not having two build systems.

• Get Nix Meson port up to date

  • Anderson: you say the meson/default.nix expression?
  • Or the current PR https://github.com/NixOS/nix/pull/3160?
  • John: Current PR, Meson build system for Nix.

• Try to improve the test story

[p01arst0rm]

meson buildsystem has been updated to work with master branch, see PR for details

[AndersonTorres]

Out of curiousity I was reading the pkgsrc-wip:

https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=tree;f=nix;hb=HEAD

There are some notes on their Makefile about bashisms and undefined symbols.

[arcuru]

Can someone clarify the status of this RFC please?

From my reading there is no decision here, but there is a request to finish the Meson PR and then to decide?

[p01arst0rm]

Can someone clarify the status of this RFC please?

From my reading there is no decision here, but there is a request to finish the Meson PR and then to decide?

the RFC has made it past most of the early stages and the current goal is to achieve parity with the current buildsystem before replacing it. any help to speed up the process of implementing the needed features is welcome:)

[eli-schwartz]

the RFC has made it past most of the early stages

But this means it hasn't gotten past the final stage and been accepted?

Is acceptance tied to implementation? Are there other outstanding concerns? Is it just waiting for a vote?

[p01arst0rm]

there's been no vote, but enough interest and support to continue:)

[AndersonTorres]

It is all running as expected. No other objections besides "not fully implemented yet" were raised as far as I remember.