Meson RFC is not accepted

[infinisil]

I might be missing something, but the Meson RFC is not accepted! Both the open letter and this explanation seem to have missed that 😅

[Ericson2314]

NixOS/nix#10378 is also now merged, and with that there is a clearer way forward for the RFC to be resolved.

[KFearsoff]

Thanks for the correction. I'll find some time to investigate the Meson situation in more detail.

Still, the standstill we are at regarding Meson doesn't make sense to me. We have had an issue in CppNix for 5 years, and then an RFC was opened 2 years ago regarding Meson. Both are still open, and we're seeing any progress only now. This seems to suggest to me that:

• Initially, Meson effort was internal to CppNix, and it was blocked indefinitely (partly because Eelco didn't want to put efforts into it)
• Discussion in CppNix went nowhere, so RFC was created to discuss the issue more openly
• The discussion in the RFC went nowhere too due to the implementation being blocked indefinitely
• Now that we have the first success on the implementation side, we can finally move forward with the RFC

Is this anywhere close to how it is? Because if it is, I'm having PTSD on multiple RFCs that went this way...

[Ericson2314]

Because it's not a user-facing detail, it was in some administrative limbo --- we don't generally have RFCs on implementation details that affect maintainers more than they affect regular users. (Of course, for Nixpkgs the distinction between the two is a lot blurrier, I don't deny that.) As an "internal" matter, it was stuck in the same limbo as other internal matters for CppNix, which is to say there was no Nix team.

In the last ~1.5 year and a half, there has been a Nix team. But it took a while to build report among ourselves, as a group of people that may not be demographically diverse, but do have differing technical opinions and priorities about Nix.

We also lacked a way to try out Meson without committing completely --- asking @p01arst0rm to make a 100% polished rewrite just for a trial phase is not fair! More recently, thinking about Hydra, I got the idea of starting with the Perl bindings as a preliminary first step --- we could rewrite that in a fully production-ready polished matter, and it still would be far less work and far less disruption than rewriting the main build system.

I conveyed this idea to @p01arst0rm, but they was a misunderstanding --- I was saying "lets just rewrite this one part first" but I was not clear enough, and @p01arst0rm thought I was saying "let's rewrite everything, as before, but starting with this one part". @p01arst0rm's interpretation of what I was saying did not come with the advantages I intended --- rather it was a bad idea that I am sorry they thought i was advocating for, and I hope they didn't waste too much time trying to follow it, wondering in quite why the hell I would want such a silly thing!

Only recently did we figure out there was a misunderstanding, and then we both quickly agreed the Perl-in-isolation approach made much more sense than the silly thing they thought I was saying instead. #10378, the result, was only opened and finalized recently (~ 1 month), and recently it was merged. Now things are back on track!

---

Long story short, "5 years" is just one of many numbers. It does reflect poorly on how CppNix was organized --- yes! --- but also reflects problems that have been fixed in that time period. The "1 month" number is valid too, and reflects what I hope is a much more reasonable pace.

[p01arst0rm]

hmm. like @Ericson2314 says, build/environment work is FAR more complicated than people give it credit for. good build systems must

• correctly build on supported platforms
• test correctly on all supported platforms
• be well documented
• be efficient
• fail gracefully
• be easily maintainable into the future
• absolutely under no circumstances break backporting

the process of designing and building a build system is an absolute nightmare. it usually involves picking apart an existing builsystem which itself often fails to follow any or all of
the above issues. if you are not careful, it is very easy to introduce design clownery which can stay in play for years into the future. the process (especially in the case of replacing the whole build system) is slow for a reason, to avoid mistakes.

A lot of the earlier work from years back was built as proof of concepts, and to assist in development of nix on non linux platforms. it was never originally designed to entirely replace the existing buildsystem.

While the meson build proved promising for its intended purpose, adoption was put on hold due to the lack of robust CI testing for the nix project. however, during that hold, the meson project matured; it showed its strengths across the open source community, leading to the move to an RFC proposal, and the change the scope of the meson build.

while i may feel that some concerns about meson aren't valid (e.g. claiming it depends on python), one valid critique that cannot be avoided is that it is a large change to the project, and must not be brushed off as a simple merge of an already existing port.

tl;dr - making build systems is 50% engineers arguing, 40% staring at the spec, 9% testing
1% actually making the thing. I really encourage anyone who doubts the efforts put into the internal design to go ahead and read any of build code and take a shot every time your eyes start to bleed

[KFearsoff]

I pushed a commit to clarify the confusion around Meson. I don't love this mistake being made in the letter itself, but I tried to do justice for the Meson, while not diminishing the point of Eelco having very much unspecified and unlimited amount of power over CppNix before Nix team was established.

Here is the commit: c7a8ff1

When you have the time, can you check if it describes the situation fairly?

[Ericson2314]

Yeah that's a big improvement. Thank you.