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
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?
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
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.
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
“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
- A new system would require learning a new programming language and its
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
- 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.
The alternatives are
It would keep the current building system confused and harder to
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!