This is a poorly-thought-out screed by longtime BSD hacker Poul-Henning Kamp, a.k.a., someone who should freaking know better. Autoconf doesn't exist because "

This is a poorly-thought-out screed by longtime BSD hacker Poul-Henning Kamp, a.k.a., someone who should freaking know better. Autoconf doesn't exist because "the bazaar" is full of lazy incompetents and only cathedrals have halfway decent design. It comes from the bad old days when "open" meant "spec documents are available under RAND terms" and had little to do with what we now call open source. Unix had splintered into lots of different idiosyncratic systems, each with its own configuration, and the GNU stuff had to run on all of them. Autoconf provided a portable way to paper over all those differences. The same with libtool. The Unix splintering had already happened when shared libs became relevant for Unix. There wasn't even agreement among the various vendors on how to implement shared libs! For example, how do you resolve the fact that a dynamic/shared library could be loaded anywhere into a process's address space, making absolute pointers inside the library invalid? There were two main schools of thought: * when linking the library, replace all exported pointers with placeholder values. Then when the dynamic linker loads the library, it swizzles the placeholder values back into pointers. (Windows) * use position-independent code, taking advantage of relative jumps, calls, and data accesses to create an object file that can be loaded anywhere. (ELF) I've seen some half-measures as well: * give each library a fixed address where it's loaded every time (Linux a.out) * punt on symbol resolution; hand the programmer a base address and have them call into the library at fixed offsets from the base (AmigaOS through 3.x) Each of the implementation strategies for shared libs required a different constellation of compiler and linker flags. Again, libtool papered over these and made it tractable to write shared libs for a variety of operating systems. It is true that these days, compiling with 'gcc -fPIC' and linking with 'gcc -shared' will probably do what you want. But that assumes a modern enough OS and toolchain, something that GNU couldn't and still cannot in some cases necessarily assume. The purpose of both these programs is to portably solve problems that were created by multiple, competing cathedrals. I don't like Autoconf or Libtool. They're unholy messes. But they're largely that way out of necessity considering the problems they solve, problems which would otherwise be nigh-intractable -- not because their developers were lazy or incompetent. And no, Meson does not solve the same problem, it punts on working on any OS that's insufficiently modern. The neat thing about the open source bazaar is that it can produce reference implementations for things everybody agrees should be in the finished product, reducing the friction of competing implementations. An example is the 86open consortium, an effort by various proprietary x86 Unix vendors (mainly BSDi, Sun, and SCO) to agree on a single binary standard for x86 Unixes. Well, the vendors got together fully expecting to get into the weeds with meetings and committees and stuff... but what they found was all their products had Linux/ELF kernel personalities already built in. So they declared Linux/ELF to be the binary standard and disbanded the 86open initiative!