Related issue: added meson support by p01arst0rm · Pull Request #3160 · NixOS/nix · GitHub
Hello, people! @p01arst0rm is writing a Meson script to build the Nix evaluator. Our idea (he, me and @Ericson2314) is to provide it as an alternative build system in the place of the current quasi-autotools.
As before, I am opening this brainstorm in order to gather ideas from a future RFC.
Please, make your comments, in the best spirit of a roasting 
As before, I am opening this brainstorm in order to gather ideas from
a future RFC.Please, make your comments, in the best spirit of a roasting
I’ve been following the PR on-and-off; I’d like to offer some help in
drafting an RFC. In the interest of being up front, I’m not involved in
development frequently enough to help out with the actual technical
transition, I have never authored or contributed to an RFC in the past,
but I am absolutely available to assist in writing/editing prose if need
be.
Oh, somehow Discourse cut this out my original email resopnse, here it is again below.
I didn’t see this brought up in the PR, so I figured I’d mention it here: IIRC, Meson is already used to build some of NIx’s dependencies. For a from-ground-level bootstrap, I don’t believe this transition would have any real effect outside a healthy decrease in build times.
This is my current draft:
Use meson as an alternative build system for the reference implementation of Nix.
Currently, the reference implementation of Nix evaluator (and its companion tools generated from the Nix source tree) is built using an autotools-like set of files.
This quasi-autotools build scripts are clunky, hard to understand and modify, besides being hard to port to other systems besides Linux.
This current state of things hinders the development of Nix, specially outside NixOS.
In light of this, we are proposing the implementation of a novel, from-scratch Meson script as an alternative build system implementation.
By doing this, we expect to accomplish
A new set of files written in Meson description language should be included in the Nix source tree, in order to coordinate the deploying process of Nix reference evaluator and its companion tools.
This novel implementation should be able to provide everything the current quasi-autotools implementation already provides, possibly with small modifications to the user interface (e.g. --enable-feature=yes would be replaced by -Dfeature=enabled).
Include here details of implementation and expected usage
The alternatives are
Doing nothing
It would keep the current building system confusing and hard to modify;
Other building systems (cmake, scons etc.)
Smooth the path between new and old build systems
--enable-feature to Meson -Dfeature=enabled options?Seems nice. Couple of typos I saw reading it:
namely Meson and
Samurai, both written in plain C plus POSIX standards.
→
namely Muon and
Samurai, both written in plain C plus POSIX standards.
specially outside the NixOS
→
specially outside NixOS
complexifying the bootstrap rooute
→
complexifying the bootstrap route
Here are some (a lot of) nits, feel free to ignore
Title: Build Nix using Meson+Ninja/Muon+Samurai
Is there anything special about Muon and Samurai? Might a more
descriptive title say something like “Build Nix with Meson, Ninja, and
Reimplementations”? If I’m interpreting the rest of the RFC and context
correctly, it looks like Muon and Samurai are just encouraged
bootstrapping methods.
Summary
Use meson language as an alternative build system for the reference
implementation of Nix language.
s/Nix language/Nix tool/? Or am I misunderstanding scope here?
Motivation
The current quasi-autotools build scripts are a bit clunky, hard to understand
and hard to port to other systems besides Linux. This current state of things
hinders the development of Nix, specially outside the NixOS.
s/specially outside the/especially outside of/
Because of it, we are proposing the implementation of a novel, from-scratch
Meson script in order to build the Nix infrastructure.
s/Because of it/Because of this/
It also looks like Meson uses “build description” instead of build
script, see Tutorial.
And again, there’s a bit of a confusion on what Nix is here. Are we
referring to the build system of the Nix tool, the Nix language, or (as
satted here) the Nix infrastructure? It’s a bit unclear what you mean by
“infrastructure”: does nixpkgs count? CI/CD? This might benefit from a
wording clarification or replacement.
We expect a better cross-compilation support, especially in other Unix-like
systems besides Linux distributions, and incidentally in other OSes like NT
Windows.
NT Windows? I don’t think Nix is ever going on there given the whole
/nix directory. It may be better to speak instead of MacOS/*BSD.
Detailed design
Meson build script files should be written and organized around the current
source code tree in order to provide an infrastructure to the typical tasks of
compilation and deployment.
s/build script files/build descriptions/? What exactly is “an
infrastructure to the typical tasks”. The grammar and phrasing here is a
bit confusing. Do you mean something more along the lines of “mechanisms
for running typical workflows”?
It should be able to provide everyting the current quasi-autotools
implementation already provides.
s/everyting/everything/. As an additional note, do we need to more
concretely define what “quasi-autotools” means anywhere in the RFC?
Examples and Interactions
Currently @p01arst0rm is writing it, and I am working on bringing Muon to
Nixpkgs.
“It” is unclear here. I take it you mean that p01arst0pm is currently
drafting a PR to convert the source tree? Additionally, while I don’t
think there’s an RFC style guide, but this may be clearer written in 3rd
person.
Drawbacks
- A new system would require learning a new programming language and its
companion tools
Hm, honestly not sure that the Meson language counts as a programming
language. It may make more sense to say something like “Currently active
maintainers would be required to adapt their workflows to the new
system.” And, if we’re going down that route for drawbacks, this would
also require some effort on the side of distro packagers, who would
largely have to rewrite their packages.
- However, the syntax of Meson is not hard to understand, especially
for those with some knowledge of Python
As a formatting note, I believe this should be part of the previous
bullet point, not part of its own.
- New tools add new dependencies
Transitive dependencies already build with Meson, this may not really be
a concern.
- Concerns about complexifying the bootstrap rooute
s/rooute/root/, otherwise a valid concern
- In particular, the reference implementation of Meson is written in Python,
whereas Ninja is written in C++
Relevance? How exactly is this a drawback?
- However, there are alternative tools to substitute it, namely Meson and
Samurai, both written in plain C plus POSIX standards.
s/Meson/Muon/?
Alternatives
The alternatives are
- Doing nothing
It would keep the current building system confused and harder to
modify
Maybe refer to the top of the RFC here rather than restating down here.
…and I think that’s all of my thoughts. Hopefully this wall of text
isn’t too overwhelming/annoying!
Nothing besides being pure (?) C implementations.
it looks like Muon and Samurai are just encouraged
bootstrapping methods.
Exactly.
s/Nix language/Nix tool/? Or am I misunderstanding scope here?
Nix tool is the reference implementation of Nix language.
It also looks like Meson uses “build description” instead of build
script, see Tutorial.
or (as satted here) the Nix infrastructure? It’s a bit unclear what you mean by
“infrastructure”: does nixpkgs count? CI/CD? This might benefit from a
wording clarification or replacement.
As far as I remember, GitHub - NixOS/nix: Nix, the purely functional package manager implements many different tools from the same codebase; in particular, because of security reasons, nix-daemon is separated from nix-env
NT Windows? I don’t think Nix is ever going on there given the whole
/nix directory. It may be better to speak instead of MacOS/*BSD.
s/build script files/build descriptions/?
Ok.
What exactly is “an infrastructure to the typical tasks”.
The typical confugurePhase && buildPhase && installPhase. Ideally, the same experience the current quasi-autotools provide should be replicated via Meson.
As an additional note, do we need to more concretely define what “quasi-autotools” means anywhere in the RFC?
The current build system is similar but not identical to autotools.
“It” is unclear here.
I need to reword this block.
Hm, honestly not sure that the Meson language counts as a programming
language.
Disclaimer here: any language that can be interpreted by a computing device, real or imaginary, is a programming language.
Yes, this definition includes HTML as a programming language, and yes again, Turing-complete is not a synonymous of programming language, but a subset of it.
Nonetheless I will reword it
this would also require some effort on the side of distro packagers, who would largely have to rewrite their packages.
OK, I will include it. On the other hand, most of current distros already had Meson in their repos, besides many softwares that use Meson as build tool.
Relevance? How exactly is this a drawback?
Including a Python interpreter and a C++ compiler is an example of complexifying the bootstrap route.
Thinking on it as a direct acyclic graph, it would like using a C compiler to build both Python and C++, in order to build both Meson and Ninja, whereas the same C compiler can build Muon and Samurai, cutting this intermediary steps.
Maybe refer to the top of the RFC here rather than restating down here.
I prefer to restate it. This is a typical interaction in many RFCs that propose modifications to the status quo, and this particular argument serves as a recapitulation.
I’m not familiar with Meson - -how does it stack to other well known C++ build tools ? (Cmake, bazel, etc…)
Edit: found Comparisons