I have never seen "configure" work particularly badly, and I've had to build some pretty hairy, dependency-ridden crap on Linux, Solaris and Mac OS X. It has held up remarkably well, and many projects are good about providing useful "configure" options. Usually fixing something requires an environment variable or configure option, and not a makefile hack.

There is no question the generated code is practically indecipherable. But you have to treat it like a compiler; no one goes leafing through the ".o" that GCC generates on a regular basis, so why worry about what "autoconf" and "automake" produce? Like any widely-used tool (such as a compiler), you can put a fair amount of trust in the maintainers to not make anything too broken; and if you see a problem, you can file a bug report.

It is also somewhat reassuring that even if the generated result is wrong, it is at least theoretically possible to fix it; just try fixing something that goes wrong in Visual Studio.

I will allow that "m4" is showing its age, and these days it's a heck of a lot easier to Google some examples and adapt them, than it is to figure out how to add a custom rule from scratch. The big challenge for the GNU Build System is to create a modern version that makes new assumptions (e.g. "perl" always exists), and update their methods accordingly.

In the former case they are sacrificing portability for increased confidence of correctness, and in the latter they are sacrificing confidence or correctness for increased portability.

That said, I still think it’s ridiculous

Now, I will fully cop to out-dated docs being annoying, particularly when most of the configuration isn't really obvious or self-documenting. But complaining about Microsoft of all people offering highly flexible text-based configurations is hugely ironic to me.

Speaking as someone who was a system administrator responsible for compiling a large number of packages across a wide variety of platforms (let's see, SunOS, Solaris, AIX, Irix, Linux, and HP-UX, all at different versions at different times) through the '90s and early 2000s, autoconf made things much, much easier.

It doesn't help the developers any; each individual difference has to be identified by the developer. (My biggest complaint isn't that it's written in m4, but that there's no comprehensive list of what I need to do with it. That information makes up the m4 tests, but there was no documentation.)

Don't like libtool? http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html

For example, "exe", "dll" and "lib" are types of projects, not of individual files: no apparent way to have multiple and heterogeneous end products (e.g dynamic libraries + static libraries + test executables + something not C/C++ like Doxygen) or to define variants like compiling the same program as a statically linked big executable or as a thin executable and a bundle of dynamic libraries.

Lack of documentation is another serious problem. For example, how do I pass exotic GCC flags and how can I ensure that qb uses GCC instead of MSVC?

"Zero configuration" in serious systems means self-configuration, e.g. automatically finding and inspecting available compilers, to provide added value over completely manual configuration; denying configuration, or at least not thinking of it because no toy example has needed it so far, isn't very productive for the end user.

I looked at it more as an option for when you want to cram out possible extra performance of release builds.

I do wish there was something more lightweight, but until I'm annoyed enough about that, I'll stick with the current state.

To change a config I need to recompile stuff? Jikes

To each their own though. I can see how this could work well if one invested a mountain of time into learning & fine-tuning it all

Your explanation was certainly satisfactory. Now I understand a bit the motivation of people who want to compile different programs depending on what happens to be installed at a particular moment in their computers. I still think that it is "an exceptionally bad idea which could only have originated in California" ;)

I ask not rhetorically, just out of curiosity. It's not a typical type of suggestion for other packages I've encountered with open source, and it feels far more difficult to discover than typical decisions at compile time.

Likewise, I'd rather distros figure out the hard way when a new release has a new feature and needs a new dependency rather than their users complain that a new feature is missing.

Principle of least surprises.

I feel like feature flags aren't that far off though. They're fantastic for many uses of runtime configuration as mentioned in another comment.

There's multiple people in this thread complaining about "abuse" of feature flags but no one has been able to voice why it's abuse instead of just use beyond esoteric dogma.

As an old-timer with ~30 years of programming experience, I have similar sentiments as the author about complex projects today, yet I also often feel that too much knowledge, accumulated in sometimes cumbersome form, is being thrown away and reinvented badly. There has to be a compromise somewhere and it's no surprise that projects in an old language like C, running on evolved systems like Unix, de facto standardized on Autoconf to make it a little easier for developers. Do I want to use it myself? Certainly not, I have the luxury of being able to choose a modern language that abstracts most (not all!) platform-specific issues away at compiler installation time, at the cost of having much fewer deployment options for my code.