Autodafe 0.2 Released For Freeing Your Project From Autotools

[phoronix]

Phoronix: Autodafe 0.2 Released For Freeing Your Project From Autotools

Eric S Raymond has released version 0.2 of Autodafe, his latest open-source project that provides "tools for freeing your project from the clammy grip of Autotools."..

https://www.phoronix.com/news/Autodafe-0.2-Released

[User42]

A lot of good will but I'd wager it's misplaced... How long until projects that migrated ask for that "hatch we really need because it makes building unwieldy otherwise" and how long until said hatch is "(ab)used" because it's there?

Building systems are complex because non-trivial projects are non-trivial to build. There is only so much tooling can do to help you solve bad design in your own projects.

I wish them success and I'd really like to be proven wrong but I won't hold my breath. Autotools is not perfect by any stretch of imagination but thinking the solution is technical is misguided IMHO.

[Hazel]

People should just migrate to cmake/mason

[jeisom]

Autotools is not perfect by any stretch of imagination but thinking the solution is technical is misguided IMHO.

Having an unreadable mess that only the most technical people can decipher is a technical problem. I’ve come across too many tiny programs that use autotools. Sure some programs/packages have lots of build options, but most are just looking to see if something is installed or not. A simple makefile in thoses cases will also tell you if it is installed by just failing to build it.

[spicfoo]

Building systems are complex because non-trivial projects are non-trivial to build. There is only so much tooling can do to help you solve bad design in your own projects.

Yes but bad tooling can make the problem worse as detailed for example here. We have continue to see an exodus of projects moving away from Autotools to alternatives like Meson and CMake and for very good reasons. Running adhoc shell scripts that check for features that existed for decades isn't a good way to maintain projects. That is needlessly complex for even trivial projects. XZ for example absolutely did not need a complex build system or any complex features at all. A bog standard and simple system is more than enough for the vast majority of projects out there.

[User42]

There's nothing I can do for you if you believe obscure build system usage is caused by autotools promoting/enforcing them... Just wait for a bit though... CMake and meson are as easy to abuse in ways that are nearly as obscure BTW.

It's a bit like when a driver, dead drunk, ran over people and blamed the car and the road. Sure, some roads (and cars) are safer than others but I'm not sure gullibly accepting the car is indeed to blame is a bit of a stretch.

In the XZ case, my argument is that with a motivated-enough party, there is always an "obscure" part of the build system/process that can be exploited and thinking that it's all just a technical problem that can be technically solved is delusional.

(And for the people who love confusing causation with equivalence, I am saying XZ-like problems cannot be solved by technical means alone, I did not say technical means won't help.)

[spicfoo]

And for the people who love confusing causation with equivalence, I am saying XZ-like problems cannot be solved by technical means alone, I did not say technical means won't help

This is an obvious strawman. Nobody is claiming what you are refuting. Everyone else is saying that technical problems exist and are working towards resolving that while you are furiously hand-wringing and providing no suggestions at all for any solutions for either category.

[Frenzie]

Having an unreadable mess that only the most technical people can decipher is a technical problem. I’ve come across too many tiny programs that use autotools. Sure some programs/packages have lots of build options, but most are just looking to see if something is installed or not. A simple makefile in thoses cases will also tell you if it is installed by just failing to build it.

When they move to a "simple Makefile" or CMake in my experience some simple cross-compilation suddenly becomes incredibly difficult. (Meson is friendlier in that regard.)

[spicfoo]

When they move to a "simple Makefile" or CMake in my experience some simple cross-compilation suddenly becomes incredibly difficult. (Meson is friendlier in that regard.)

Depends on the project. Autotools itself can hinder cross compilation if your needs go beyond *nix systems. This is in fact a major reason for the move to Meson or CMake. You are correct that Meson is friendlier in that regard.

[mathletic]

Even LibreOffice has not understood that it should stop using Autotools, see https://bugs.documentfoundation.org/...i?id=113121#c4

Both CMake or Meson would would make building and maintaining the project so much easier. On the other hand, ESR proposing to switch to plain Makefiles is ill-advised: No easy detection of the build environment, detection of available dependencies, altering configuration flags, abstraction of C++-specific fiddling, and a high level abstraction.