> 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.

> Building/compiling for Linux is soooo much worse than literally every other platform. It's stuck in the 70s.

I find compiling software in Debian so much easier than alternatives. Usually it’s just a matter of installing the build deps in apt (since usually some version is packaged already) and then running configure, make, etc. I’m pretty surprised you describe the process as so bad.

> Usually it’s just a matter of installing the build deps in apt

I expect to clone, build, run.

In practice it’s: clone, build, read compile error, google the dependency, install the dependency, build again, see new error, repeat 10 times.

That is of course just a small percentage of the pain.

You’ll notice that the most reliable Linux API for playing games is… Win32 via Proton. build-essentials doesn’t provide a way to target an arbitrarily old version of glibc because the way shared libraries are linked is ass backwards and ./configure is a terrible design.

> In practice it’s: clone, build, read compile error, google the dependency, install the dependency, build again, see new error, repeat 10 times.

This just isn't my experience. I just run apt build-dep and it just _works_. It works basically every single time. Have you tried doing the same?

I'm not saying there aren't issues, just that my experience with compiling code on Linux is much easier than anywhere else. Of course Windows apis are much more stable, but that's never much a barrier to building code for me.

Edit: By the way even if you run into build problems, I still don't see how it's an issue with Linux. Projects that can't easily be built with very clear instructions need to improve their instructions. Lazy developers will always produce badly documented software. That's an unfortunate fact of life.

There is a certain "Linux philosophy" such that the user expected to have a kajillion different things installed into the global path. If your environment isn't precisely correct either it won't build or it won't run. I find that philosophy less common for other platforms.

My personal experience is that Linux is FAR AND AWAY the most painful OS to develop for. I fully admit I'm not a Linux expert! Getting anything done requires a LOT of Googling and running of arcane commands. It's quite frustrating.

Nix provides a sane way to manage dependencies. Unfortunately it comes with a language that will drive you insane.