solution for a problem that should
not exist in the first place. Even more
maddening is that 31,085 of those
lines are in a single unreadably ugly
shell script called configure. The idea
is that the configure script performs
approximately 200 automated tests,
so that the user is not burdened with
configuring libtool manually. This
is a horribly bad idea, already much
criticized back in the 1980s when it
appeared, as it allows source code
to pretend to be portable behind the
veneer of the configure script, rather
than actually having the quality of
portability to begin with. It is a travesty that the configure idea survived.
The 1980s saw very different Unix
implementations: Cray-1s with their
24-bit pointers, Amdahl UTS mainframe Unix, a multitude of more or
less competently executed SysV+BSD
mashups from the minicomputer
makers, the almost—but not quite—
Unix shims from vendors such as
Data General, and even the genuine
Unix clone Coherent from the paint
company Mark Williams.
The configure scripts back then
were written by hand and did things
like figure out if this was most like a
BSD- or a SysV-style Unix, and then
copied one or the other Makefile and
maybe also a .h file into place. Later
the configure scripts became more
ambitious, and as an almost predictable application of the Peter Principle, rather than standardize Unix to
eliminate the need for them, somebody wrote a program, autoconf, to
write the configure scripts.
Today’s Unix/Posix-like operating systems, even including IBM’s z/
OS mainframe version, as seen with
1980 eyes are identical; yet the 31,085
lines of configure for libtool still
checks if <sys/stat.h> and <stdlib.h>
exist, even though the Unixen, which
lacked them, had neither sufficient
memory to execute libtool nor disks
big enough for its 16MB source code.
How did that happen?
Well, autoconf, for reasons that
have never made sense, was written in
the obscure M4 macro language, which
means the actual tests look like the example in the accompanying figure.
Needless to say, this is more than
most programmers would ever want
to put up with, even if they had the
skill, so the input files for autoconf
happen by copy and paste, often
hiding behind increasingly bloated
standard macros covering “standard
tests” such as those mentioned earli-
er, which look for compatibility prob-
lems not seen in the past 20 years.
Open vs. Closed: Which Source
is More Secure?
The hyperdimensional Tar Pit
1. brooks, F. The Design of Design. addison-Wesley
2. raymond, e. The Cathedral and the Bazaar. o’reilly
Media, sebastapol, Ca, 1999.
Poul-henning Kamp ( phk@Freebsd.org) has
programmed computers for 26 years and is the inspiration
behind bikeshed.org. his software has been widely
adopted as under-the-hood building blocks in both open
source and commercial products. his most recent project
is the Varnish httP accelerator, which is used to speed up
large Web sites such as Facebook.