autoconf: Exodus

1 
1 21.2 Exodus
1 ===========
1 
1 As I got feedback from users, I incorporated many improvements, using
1 Emacs to search and replace, cut and paste, similar changes in each of
1 the scripts.  As I adapted more GNU utilities packages to use
1 `configure' scripts, updating them all by hand became impractical.
1 Rich Murphey, the maintainer of the GNU graphics utilities, sent me
1 mail saying that the `configure' scripts were great, and asking if I
1 had a tool for generating them that I could send him.  No, I thought,
1 but I should!  So I started to work out how to generate them.  And the
1 journey from the slavery of hand-written `configure' scripts to the
1 abundance and ease of Autoconf began.
1 
1    Cygnus `configure', which was being developed at around that time,
1 is table driven; it is meant to deal mainly with a discrete number of
1 system types with a small number of mainly unguessable features (such as
1 details of the object file format).  The automatic configuration system
1 that Brian Fox had developed for Bash takes a similar approach.  For
1 general use, it seems to me a hopeless cause to try to maintain an
1 up-to-date database of which features each variant of each operating
1 system has.  It's easier and more reliable to check for most features on
1 the fly--especially on hybrid systems that people have hacked on
1 locally or that have patches from vendors installed.
1 
1    I considered using an architecture similar to that of Cygnus
1 `configure', where there is a single `configure' script that reads
1 pieces of `configure.in' when run.  But I didn't want to have to
1 distribute all of the feature tests with every package, so I settled on
1 having a different `configure' made from each `configure.in' by a
1 preprocessor.  That approach also offered more control and flexibility.
1 
1    I looked briefly into using the Metaconfig package, by Larry Wall,
1 Harlan Stenn, and Raphael Manfredi, but I decided not to for several
1 reasons.  The `Configure' scripts it produces are interactive, which I
1 find quite inconvenient; I didn't like the ways it checked for some
1 features (such as library functions); I didn't know that it was still
1 being maintained, and the `Configure' scripts I had seen didn't work on
1 many modern systems (such as System V R4 and NeXT); it wasn't flexible
1 in what it could do in response to a feature's presence or absence; I
1 found it confusing to learn; and it was too big and complex for my
1 needs (I didn't realize then how much Autoconf would eventually have to
1 grow).
1 
1    I considered using Perl to generate my style of `configure' scripts,
1 but decided that M4 was better suited to the job of simple textual
1 substitutions: it gets in the way less, because output is implicit.
1 Plus, everyone already has it.  (Initially I didn't rely on the GNU
1 extensions to M4.)  Also, some of my friends at the University of
1 Maryland had recently been putting M4 front ends on several programs,
1 including `tvtwm', and I was interested in trying out a new language.
1