De-Autoconfiscation (Eric Raymond)

> The important thing to know is that config.h/Makefile generation is complex mainly because of API portability issues that have been mostly obsolesced by increasing standardization around C99 and SuSv2 (the Single Unix Standard, version 2, descended from POSIX). Standardization on GNU Make has also addressed some (though not all) of the portability issues in Makefiles.

Generating config.h was maybe a good idea in the 90s (I'm not convinced). But in this day and age it's a mistake.

These days all of my projects support Windows, mac, linux, and Android. Zero of them use autotools or generate a config.h. The whole concept of "discover capabilities of the system" is bad, broken, and these days unnecessary. Any type of "glue" code to abstract across slight differences between targets shouldn't be handled by the build system. It should be written by one person once ever and committed to source.

Building computer programs doesn't have to be complex and painful. The primary reason people think it's complex is because our build tools are stuck in the 90s.

"Won’t we lose platforms that aren’t Linux or BSD?" Well, as a mostly-mac user these days, a sane Makefile that I can understand and fix is much preferrable to some automake-generated monstrosity that does not work...

Which leads us to my next point: The article talks about autotools, but only seems to address autoconf. As long as projects used a hand-made Makefile.in, it was, in my experience, usually possible to skip running autoconf and edit the Makefile and config.h manually, if the autoconf script turned out to be completely inadequate. It was the introduction of automake that turned makefiles into an inscrutable mess, where everything happened through four levels of variable expansion.

> You lose the ability to set system directories for installation to non-default versions using options of configure; instead, you have to tweak the variable definitions in your makefiles directly. Same applies to options custom for your project.

This is probably the biggest loss. Maybe it's possible to preserve this with bare makefiles?

Or maybe make -DSOMETHING would already work anyway?

Makefiles don't scale all that well as portability and platform-specific gotchas lead to software configuration management headaches.

Cmake is a step in the direction of creating a maintainable and simple portability layer. It can create Makefiles or use other build systems like Ninja (I prefer the compatible and faster samurai tool).

There is a tool called "just", but it doesn't know anything about caching dependency management, which is a step backwards and wastes resources unnecessarily. That is a case of erroneously eliminating essential features in the pursuit of solving other problems.

Tools like meson, conan, and bazel are sometimes overkill and tend to lack essential features (like creating static libraries).

KISS. Create simple, straightforward, and documented ways to build, install, uninstall, clean, and run tests.

I appreciate the pragmatic approach. Makefiles are the worst solution for running builds, except for all the others that have been tried.