# Brainstorming for RFC: Using Meson to build Nix evaluator

**URL:** https://discourse.nixos.org/t/brainstorming-for-rfc-using-meson-to-build-nix-evaluator/21141
**Category:** Development
**Created:** [August 21, 2022, 5:23pm UTC](https://discourse.nixos.org/t/brainstorming-for-rfc-using-meson-to-build-nix-evaluator/21141 "2022-08-21T17:23:26Z")
**Posts on this page:** 1
**Showing post:** 7

<div class="post-metadata">

### Author: ![anon20203487](https://discourse.nixos.org/letter_avatar_proxy/v4/letter/a/7cd45c/32.png) [@anon20203487](https://discourse.nixos.org/u/anon20203487)
#### Post date: [August 21, 2022, 9:47pm UTC](https://discourse.nixos.org/t/brainstorming-for-rfc-using-meson-to-build-nix-evaluator/21141/7 "2022-08-21T21:47:37Z")

</div>

> [@amaproblem](#):
>
> Is there anything special about Muon and Samurai?

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](https://mesonbuild.com/Tutorial.html).

> 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](https://github.com/NixOS/nix) 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.

> [@Nix on Windows?](https://discourse.nixos.org/t/nix-on-windows/1113):
>
> Is anyone trying to port nix and nixpkgs to output native Windows PE executables? I would like to avoid cross-compilation and cygwin if possible to get something as close as native as possible. I talked a bit with @edolstra and he said the following things: it is (was) possible to build non-cygwin binaries, e.g. [\* A Hello World GUI application compiled with VC++. · NixOS/nixpkgs@08d3840 · GitHub](https://github.com/NixOS/nixpkgs/commit/08d3840c94aa4016cdab441751ac78692dc600e2) we used to have Visual C++ in Nixpkgs probably nowadays we would want to use WSL instead of Cygw…

> 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.

---

_[View the full topic](https://discourse.nixos.org/t/brainstorming-for-rfc-using-meson-to-build-nix-evaluator/21141)._
