Autotools was very good at configuring build in quite diverse Unix (posix) environments most of which have now vanished. Pre-2000 you might have had a basic Unix System III derived system with various vendor modifications running on a proprietary CPU etc with possibly quite peculiar toolchains. The included software was normally quite mimimal and the vendor would nickel and dime* you for any add on software (including the toolchain.)
Consequently otherwise identical systems diverged in the various layers off user built and installed software. This is the world in which autotools excelled.
Autodafe appears to take advantage of the fact the world has crystallized into Linux and *BSD which are remarkably homogeneous - you can pretty much depend on gcc or a llvm compatible C compiler, the C standard libraries (a post 1990 luxury) , a posix interface (unistd.h) and so on.
I imagine you can visualize autoafe taking the extremely versatile and dynamic autotools environment and applying static definitions from (linux/bsd/posix), optimizing (dead code elimination, etc) and emitting static Makefiles (nothing other than implicit rules, targets and dependencies, and flag (and other) definitions) which partially address the xz fiasco.
For distros producing such Makefiles for the source packages could largely eliminated the need for autotools in the users build environment. Quite a few RPM spec files use autotools to configure their packages.
The Mirriam Webster has -
Auto-da-fe: the ceremony for pronouncing judgment by the Inquisition which was followed by the execution of sentence by secular authorities.
broadly : the burning of a heretic
* multiplied by several orders of magnitude.
Consequently otherwise identical systems diverged in the various layers off user built and installed software. This is the world in which autotools excelled.
Autodafe appears to take advantage of the fact the world has crystallized into Linux and *BSD which are remarkably homogeneous - you can pretty much depend on gcc or a llvm compatible C compiler, the C standard libraries (a post 1990 luxury) , a posix interface (unistd.h) and so on.
I imagine you can visualize autoafe taking the extremely versatile and dynamic autotools environment and applying static definitions from (linux/bsd/posix), optimizing (dead code elimination, etc) and emitting static Makefiles (nothing other than implicit rules, targets and dependencies, and flag (and other) definitions) which partially address the xz fiasco.
For distros producing such Makefiles for the source packages could largely eliminated the need for autotools in the users build environment. Quite a few RPM spec files use autotools to configure their packages.
The Mirriam Webster has -
Auto-da-fe: the ceremony for pronouncing judgment by the Inquisition which was followed by the execution of sentence by secular authorities.
broadly : the burning of a heretic
* multiplied by several orders of magnitude.
Comment