Hi, On 3/24/26 7:22 AM, Paul Fertser wrote:
I could never understand how it happened that popular build systems ended up inventing their own unique languages (with all the downsides mentioned) instead of e.g. Lua if they wanted something like traditional scripting features. I also do not understand why people do not seem to desire a purely functional approach to specifying builds.
They desire a purely descriptive approach, then that collides with reality, then they go for a functional language, then that collides with reality, then they hack something together in perl.
The things that autotools do right are more on the subtle side, like "Conditionals are single words.", so if there is a complex condition attached to anything, it needs to be resolved at a central point, not repeated as an expression at each site (because these expressions then grow unmanageable).
Nothing stops us from doing that in other languages, it's just not as enforced. Whatever language is chosen, it needs to be complemented with a policy "what goes where".
The other thing they kind of do right (but could do better) is cross-compiling: pretty much every test that is provided is written with cross-compiling in mind. Meson strives to achieve that as well, but CMake is a lost cause in that regard, I get the feeling that their "CMake is easy" stance has led to a community that expects that contributing a test to CMake should also be easy -- but at some point, someone will have to deal with all the complexity, and they have decided to outsource that to the person willing to cross-compile ("you need to provide a file with variables that override all the tests that go wrong").
What they could do better is provide a framework for multi-target projects. The GNU toplevel generator can in principle do that, but it is written with the full complexity of the problem in mind (where you have to bootstrap a compiler for some targets first).
OpenOCD, I believe, has a requirement to build code for several target architectures in one invocation, and while "run the configure script once for each target" is not great, it's at least doable. It might also be doable with Meson, but it requires the same dance as with the autotools, because while they do support more than two machine types (build/host) in principle, they expose it as a boolean "native" only.
the whole concept isn't elegant from CS point of view (text macro processing to generate quirky imperative language script is meh) but it /felt/ kind of fun and satisfying.
From a pure CS point of view there is nothing more elegant than a compiler that works by pure iterative text replacement.
I personally would rather learn some strongly-typed purely functional DSL for the task...
The OpenOCD build system has requirements that only 1% of projects have. Designing a structured DSL that covers these requirements is a really hard task, and pretty much all existing build systems will refer us to their convenient escape hatch for all cases not currently covered -- and the annoying thing is that autotools has the nicest escape hatch, because it's not an obvious afterthought.
Simon
