Re: Compiling NetBSD mtree in-tree with meson.build

On 1/16/25 03:41, Mouse wrote:

> I'm no fan of autotools.  But I think I like meson even less.  It
> requires installing a whole new language (python); while this may be
> acceptable for NetSBD's own build procedure, it significantly raises
> the bar for cross-building pieces - if I have to not just copy over the
> program's source but also install python?  Honestly, I'd more likely
> try to figure out enough from the meson description file(s) to build it
> manually.

Meson is a quite decent build system but I too dislike the fact that 
it's implemented in Python. IMO a language must either maintain 
backwards compatibility (like C and Perl) or extensive compile-time 
error checks (like C++, Rust, and Haskell) but Python has neither of 
these. Even a minor update to Python breaks existing code in a subtle 
way, and the breakage doesn't show up promptly. Ruby has the same problem.

> More generally, I don't really understand the recent proliferation of
> autotools-replacement build systems.  cmake, meson, ninja, etc, they
> all appear to be trying to reinvent make and/or autotools as the tool
> designer thinks they should have been, and they all appear to think
> that installing a new, complex, and almost totally unsandboxable tool
> as the first step to building the software you're trying to build is
> completely acceptable.

But there's a downside to Autoconf's approach: it pushes complexity down 
to generated shell scripts and Makefiles. Humans cannot bother to audit 
those generated files. This is how the XZ backdoor went unnoticed: a 
part of the malicious code was hidden in the generated "configure" 
script while its source, configure.ac, was left unmodified.