tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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.

Home | Main Index | Thread Index | Old Index