Skip to content

Commit 18772a6

Browse files
[RFC 0132] Meson Builds Nix (#132)
* Use Meson to build Nix * Modify feature attribute `meson_builds_nix` is a more cool name. * Small clarification * Reformulates the alternatives section * Answer new drawback * Typo * Rewording * Unfill the paragraphs * Rename RFC file * Small punctuation fixes * Rewording * Add usage example * Add references * Improvements on the wording * Reword the reference to Nix It is unneeded to make a distinction between Nix language and its implementation. * Typo projec -> project * Typo Word "we" was lost. * Reword a paragraph * Reword the detailed design * Reword the examples A comparison table is cleaner than a dot list. * Add a paragraph about the current (quasi-) autotools * Reword commentary about transition * Reword alternatives * Reword commentary about Cmake * Remove commentary about backport * Bring more items to future work * Add references Two tutorials from NetBSD and Meson docs about converting autotools to Meson. * Reorder references * Reword motivation section * Reword paragraph * Rework examples and interactions * Rework drawbacks * Rework alternatives * Some fixups * Include some more examples of build systems * Reorder references * Reword cmake subsection * Move paragraphs about Meson and Ninja to detailed design section * Remove unneeded paragraph * Include Bazel as alternative Because maybe someone out there believes it is good and viable to cite it ... * Reword paragraph * Punctuation * More references * Reword * Typo * Reword * A bit more about Bazel For the sake of completeness. * add feature: out-of-source build * Typos, typos and more typos * Link to the now free-as-in-beer book from the creator of Meson * Another typo * Add shepherds * add cross-compilation support to the criteria of evaluation of alternatives * Typo * Reword examples * Add some more advantages for Bazel * Reword and add more disadvantages for Bazel * More references * Reword Google company name * Add Prior Art section * Rewords and comparisons --------- Co-authored-by: Eelco Dolstra <[email protected]>
1 parent 25c3f52 commit 18772a6

File tree

1 file changed

+241
-0
lines changed

1 file changed

+241
-0
lines changed

rfcs/0132-meson-builds-nix.md

Lines changed: 241 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,241 @@
1+
---
2+
feature: meson_builds_nix
3+
start-date: 2022-08-25
4+
author: Anderson Torres
5+
co-authors: @p01arst0rm
6+
shepherd-team: @Ericson2314 @edolstra @thufschmitt
7+
shepherd-leader: @Ericson2314
8+
related-issues:
9+
---
10+
11+
# Summary
12+
[summary]: #summary
13+
14+
Use meson as an alternative build system for Nix.
15+
16+
# Motivation
17+
[motivation]: #motivation
18+
19+
Currently, the Nix evaluator and its companion toolset generated from the Nix source tree are built using the typical `./configure` shell script that relies on autoconf, along with standard GNU Make utility.
20+
21+
Over time, this build system has been modified to keep up with the development needs of Nix project. However, it has reached a state where the build system became clunky and plastered, hard to understand and modify, consequently making improvements to the project as a whole very difficult.
22+
23+
In particular, many changes have been introduced that impact compatibility outside Linux and NixOS niches. These issues can hinder development on other platforms, including but not limited to Unix-like systems.
24+
25+
In light of this state of things, we propose a novel alternative to the current building infrastructure.
26+
27+
We expect to accomplish, among other goals,
28+
29+
- better code structuring and documentation;
30+
- improved support across platforms, especially outside NixOS and Linux;
31+
- shorter build times;
32+
- improved testing;
33+
- more reasonable dependency management;
34+
- an overall improved user experience.
35+
36+
# Detailed design
37+
[design]: #detailed-design
38+
39+
## What is Meson?
40+
41+
Meson is an open source, multiplatform build system crafted to be fast, correct and user-friendly.
42+
43+
According to its main site,
44+
45+
> The main design point of Meson is that every moment a developer spends writing or debugging build definitions is a second wasted. So is every second spent waiting for the build system to actually start compiling code.
46+
47+
Among its features, we highlight:
48+
49+
- user-friendly non-Turing complete DSL
50+
- Python-esque syntax and functional, stateless semantics
51+
- multiplatform support
52+
- among operating systems: Linux, *BSD, Apple MacOS, Microsoft Windows NT
53+
- among programming environments: GCC, Clang, Xcode, Visual Studio etc.
54+
- among programming languages: C, C++, D, Fortran, Java, Rust etc.
55+
- supports command customization
56+
- cross compilation
57+
- many useful modules included (pkg-config, filesystem inspection, internationalization etc.)
58+
- out-of-source build support
59+
- indeed, meson does not support inside-source build
60+
- Comprehensive documentation
61+
- including tutorials, reference manuals and real world projects using it
62+
63+
## What is Ninja?
64+
65+
Ninja is a small, speed-focused build tool that fills a similar role of Unix `make` or its GNU counterpart `gmake`.
66+
67+
Its main feature is a low-level approach to build description. Ninja is bare-bones and constrained by design, having only the necessary semantics to describe build dependency graphs, relegating decision-making to superior tools like Meson or CMake. Where other build systems act like high level languages, Ninja acts like an assembly.
68+
69+
Albeit Ninja DSL is human-readable, it is not convenient to be manually written by human beings. As said before, Ninja is commonly used in tandem with other, higher-level build system in a two-pass fashion. In our present use case, the Meson interpreter converts Meson files to Ninja files that will be consumed by Ninja tool to effectively execute the building/deployment commands.
70+
71+
## Design
72+
73+
A carefully crafted set of Meson files should be included in order to describe how to deploy the Nix repository, generating all the expected artifacts (command line tools, libraries, configuration files, documentation etc.)
74+
75+
This novel building infrastructure should be able to provide at least feature parity with the current quasi-autotools implementation, albeit in a different user interface.
76+
77+
# Examples and Interactions
78+
[examples-and-interactions]: #examples-and-interactions
79+
80+
## Example interaction
81+
82+
Here is a table comparing some expected interactions:
83+
84+
| Action | Current | Meson+Ninja | Meson, backend-agnostic |
85+
|-----------|--------------------------------|--------------------------------------|--------------------------------------|
86+
| Configure | `./configure --enable-gc=true` | `meson setup build_dir -Dgc=enabled` | `meson setup build_dir -Dgc=enabled` |
87+
| Build | `make` | `ninja -C build_dir build` | `meson -C build_dir compile` |
88+
| Install | `make install` | `ninja -C build_dir install` | `meson -C build_dir install` |
89+
| Uninstall | `make uninstall` | `ninja -C build_dir uninstall` | `meson -C build_dir uninstall` |
90+
91+
## Implementation
92+
93+
Currently, @p01arst0rm is working on an implementation from scratch.
94+
95+
# Drawbacks
96+
[drawbacks]: #drawbacks
97+
98+
Below we will list some possible drawbacks and balances to them.
99+
100+
## Complexity and Bootstrap Issues
101+
102+
A new build system, and any build system for that matter, indirectly brings its own dependencies to the Nix project.
103+
104+
Ideally, such dependencies should be minimal, both in number and complexity, with extra good points for dependencies already present (e.g. the ubiquitous C compiler).
105+
106+
About this specific point, a non-negligible drawback is: the reference implementation of Meson is written in Python. At least theoretically, it brings the necessity of including a Python 3 interpreter on the _bootstrap route_ of Nix.
107+
108+
However, some points can be laid out on the opposite side:
109+
110+
1. By design, the meson reference evaluator depends only on Python, avoiding the use of extra libraries.
111+
2. Also by design, the implementation language is never exposed to the meson DSL. It allows the possibility of implementing alternative evaluators in other programming languages.
112+
1. Indeed, Muon is an alternative implementation of Meson written in C.
113+
3. In order to evaluate the impact of this new bootstrap route, we should also evaluate the current bootstrap route, in order to have a fair comparison.
114+
115+
In principle, the same criticisms and answers can be laid out for Ninja too; however, Ninja is written in C++, a language already used to implement Nix. Therefore, the bootstrap route suffers little to no alteration here.
116+
117+
## Learning the new system
118+
119+
A somewhat subjective but non-negligible issue is the entry barrier of this new build system. Switching from a known build system to one unknown is not without its problems.
120+
121+
However, the Meson development team strives to keep the DSL easy to learn and pleasurable to use. It should not be hard to become familiar with the Python-esque syntax of meson, and its functional, stateless approach is certainly a feature highly appreciated by the Nix community as a whole.
122+
123+
The huge advantages of implementing Meson surpass the small drawbacks of learning it.
124+
125+
Further, the current barrier of entry should be evaluated in order to have a fair comparison.
126+
127+
## Source code changes
128+
129+
Further to the obvious inclusion of meson files (and the removal of the old quasi-autotools ones), there is a reasonable expectation of code refactoring.
130+
131+
However, such refactorings are completely validated on the long term goals of Nix, in particular the improvements on portability.
132+
133+
## End users
134+
135+
The most known end user of Nix is certainly Nixpkgs. However, there are many other Linux distributions that already keep Nix on their repositories (15 families, according to Repology). There is also a reasonable expectation of affecting those package managers' devteams.
136+
137+
However, most (if not all) of those distributions already have Meson and its companion tool Ninja in their respective package databases (53 families, according to Repology), given that many open source projects use them as build system.
138+
139+
## Transition between old and new build infrastructure
140+
141+
The transition between old and new build systems should be as smooth and controlled as possible.
142+
143+
# Alternatives
144+
[alternatives]: #alternatives
145+
146+
The alternatives are
147+
148+
- Do nothing
149+
150+
It would keep the current code confusing and harder to work with, as stated on the motivation section.
151+
152+
- Use CMake
153+
154+
Indeed, CMake has many noteworthy advantages:
155+
156+
- Supports typical high level idiomatic constructions.
157+
- Can generate GMake- and Ninja-compatible scripts.
158+
- By design, Meson does not provide a Make backend.
159+
- Both Meson and CMake support Microsoft Windows NT and Apple MacOS platforms
160+
- As well as MSVC and XCode programming environments.
161+
162+
However, CMake DSL is arguably more complex and cumbersome, whereas Meson is more polished.
163+
164+
- Evaluate other building systems (waf, scons, premake, xmake etc.)
165+
166+
About this, a principle should be observed:
167+
168+
Per the bootstrap route issue discussed above, build tools strongly tied to other programming languages are severely discouraged.
169+
170+
E.g. waf and scons are Python libraries in essence, whereas premake and xmake are Lua libraries. They can't be decoupled of their implementation languages.
171+
172+
Another indispensable attribute to be considered is cross-compilation support.
173+
174+
- Use Bazel
175+
176+
For the sake of completeness, there is Bazel, a Google LLC-backed build system that sells itself as "fast, scalable, multi-language and extensible".
177+
178+
Advantages:
179+
180+
- Fast, scalable, multi-language and extensible.
181+
- Your mileage may vary.
182+
- Trusted by industry leaders.
183+
- Backed by Google.
184+
185+
Disadvantages:
186+
187+
- [Too tied to Google internals](https://bazel.build/about/faq#why_isn%E2%80%99t_all_development_done_in_the_open)
188+
- [Not fully open source yet](https://bazel.build/about/faq#are_you_done_open_sourcing_bazel)
189+
- Written in Java
190+
- Java bootstrap is fairly complex, currently relying on _open-source abandonware_, as demonstrated by [Bootstrappable](https://bootstrappable.org/projects/java.html) project.
191+
- At the current time there is no alternative implementation of Bazel in another programming language.
192+
- Backed by Google.
193+
194+
# Prior Art
195+
196+
For the sake of completeness, and pushed by the advent of [RFC Process updates](https://github.com/NixOS/rfcs/pull/150), we are including here a list of projects that are in different stages of transition to Meson:
197+
198+
- [GNOME](https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting)
199+
- [X.Org Server](https://gitlab.freedesktop.org/xorg/xserver)
200+
- [XTS](https://gitlab.freedesktop.org/xorg/test/xts), the X.Org Test Suite
201+
- [MPV](https://mpv.io), the commandline video player
202+
- [GIMP](https://gitlab.gnome.org/GNOME/gimp), the GNU Image Manipulation Program
203+
- [Mesa](https://mesa3d.org/), the open source implementations of many low-level, graphics-related libraries
204+
205+
# Unresolved questions
206+
[unresolved]: #unresolved-questions
207+
208+
Questions that deserve further inquiry:
209+
210+
- Unexpected interactions with Meson and Ninja
211+
- Specially, vendoring and reproducibility.
212+
213+
# Future work
214+
[future]: #future-work
215+
216+
- Update project's continuous integration and related stuff;
217+
- Deprecate and remove the current quasi-autotools scripts
218+
- Preferably, the removal should be allocated to a minor version release.
219+
- Evaluate the positive and negative impacts of such a change
220+
- Specially the most subjective ones.
221+
222+
# References
223+
[references]: #references
224+
225+
- [Meson](https://meson.build/)
226+
- [Muon](https://muon.build/), a C99 alternative implementation
227+
- [Ninja](https://ninja-build.org/)
228+
- [Samurai](https://github.com/michaelforney/samurai), a C99 alternative implementation
229+
- [Meson tutorial](https://mesonbuild.com/Porting-from-autotools.html) comparing autotools and Meson
230+
- [NetBSD tutorial](https://wiki.netbsd.org/pkgsrc/how_to_convert_autotools_to_meson/) comparing Meson and autotools
231+
- [Boostrappable Builds](https://bootstrappable.org/)
232+
- [CMake](https://cmake.org/)
233+
- [Premake](https://premake.github.io/)
234+
- [Waf](https://waf.io/)
235+
- [SCons](https://scons.org/)
236+
- [Xmake](https://xmake.io/)
237+
- [Bazel](https://bazel.build)
238+
239+
- [Free-to-read book from the creator of Meson](https://nibblestew.blogspot.com/2021/12/this-year-receive-gift-of-free-meson.html)
240+
241+
- [Current work in progress from @p01arst0rm](https://github.com/NixOS/nix/pull/3160)

0 commit comments

Comments
 (0)