I felt like the author did realize that, and the "written by the devil" comment was a direct reference to autoconf (which certainly qualifies as a devil). Who knows, though.

zetalyrae also correctly pointed out that much of the text is "handwritten but transcluded". Most of the code snippets that appeared in autoconf was originally written by hand and stored in reusable modules, including 100+ tests in autoconf. So overall the volume of code is still huge.

I guess it at least demonstrated the power of modularity. Almost nobody can understand it, but it still works...

As far as configure is concerned, I'd like to add that 16394 is close to 2^14, not 2^16.

Yes, I got the exponent wrong.

Anyway, I lol'd hard at "written by the devil." Thanks for the article.

Bash is not an acceptable compilation target. And much of the text is handwritten but transcluded.

> Bash is not an acceptable compilation target

The whole point of autotools is to make sure that your project can run on the largest possible set of unix-like operating systems.

`sh` is actually the very best compilation target for that, looking back in time, whatever other language that could have been chosen (most likely perl) would have been a huge mistake.

The alternative is a C program querying the filesystem (or, better yet, a database and a daemon to prevent duplicate ./configure work).

I don't think you understand the role of autoconf... The whole point is that you _don't know_ yet what compiler is available, which version/flavor of C is supported, which API or syscall are available, etc.

Autoconf was litterally made so that you can write C code that is somewhat portable. Suggesting that it should have been written in C and built locally is non-sensical.

Doesn't cmake do this job too?

I don't think cmake has feature parity with autotools.

Not in my personal experience anyway.

CMake-based build systems require you to have CMake installed. Guess how CMake is bootstrapped on *nix systems? autotools!

I meant a compiled binary program.

> Oh hai! -bootstrapping problem

/bin/sh is available for all of those platforms. So why not an interpreter for a typed language?

Well first because autoconf/automake were built in the early 90s. It's not like there were a ton of choices back then.

Basically if you wanted something that 1) is available on all Unix-like flavors and 2) is strictly well defined and standardized, you could count them on a single hand fingers.

I guess the candidates were sh, awk, make, m4 and perl.

sh had the advantage of being ubiquitous, somewhat well understood by everyone, strictly defined (an sh-compatible shell at /bin/sh was mandated by Posix/SUS, which had (and still have) quite good traction even for non-strictly unix/posix Oses)

Note that even by today's standards, "sh" is probably the only thing you can be 100% sure is available whatever the Unix flavor, even on the most minimal build imaginable.

I cannot say I can think of anything as well defined and supported even today.

Python? Ok but which specific version? Most distribs struggled to migrate to Python 3 for the very reason that system-wide python 2 usage was pervasive in base utilities (yum, etc). If Python 2 would have been chosen as autoconf target, imagine the nightmare we would be in today.

Perl? I guess it could have been the strongest candidate after sh. Present me is happy that it was not chosen though, as we seldomly see any Perl nowadays, while sh is still quite well used and understood.

sh is also quite well suited IMHO for the kind of things you do with autoconf/automake/make. Some examples that come to my mind:

- Cleanup some directories / intermediary files

- grep / find / sed some configuration from config files to .h/.pc

- Lookup for ad-hoc libraries on the filesystem

- Archive / build your dists

- etc

Now dont get me wrong, I won't say autotools are a brease to work with. Especially I have a profound hate of m4.

Pragmatically though, once you tame the beast, it does the job it was made to do pretty darn well.

If I recall correctly, the original compilation target is not even /bin/bash but the /bin/sh. Originally, the ./configure script generated by autoconf must run on several incompatible flavors of Unix at that time, including AIX, SunOS, and BSD, powered by several different CPU architectures, such as x86, Alpha, SPARC, and MIPS, so shipping binaries or using the Bash syntax was not acceptable. It must strictly use the original sh syntax. Though I suspect lots of Bashism has lurked in over the years since nobody still tests it anymore.