(autoconf.info)Exodus

---

Next: Leviticus Prev: Genesis Up: History

---

Enter node , (file) or (file)node

14.2 Exodus
===========

As I got feedback from users, I incorporated many improvements, using
Emacs to search and replace, cut and paste, similar changes in each of
the scripts.  As I adapted more GNU utilities packages to use
'configure' scripts, updating them all by hand became impractical.  Rich
Murphey, the maintainer of the GNU graphics utilities, sent me mail
saying that the 'configure' scripts were great, and asking if I had a
tool for generating them that I could send him.  No, I thought, but I
should!  So I started to work out how to generate them.  And the journey
from the slavery of hand-written 'configure' scripts to the abundance
and ease of Autoconf began.

   Cygnus 'configure', which was being developed at around that time, is
table driven; it is meant to deal mainly with a discrete number of
system types with a small number of mainly unguessable features (such as
details of the object file format).  The automatic configuration system
that Brian Fox had developed for Bash takes a similar approach.  For
general use, it seems to me a hopeless cause to try to maintain an
up-to-date database of which features each variant of each operating
system has.  It's easier and more reliable to check for most features on
the fly--especially on hybrid systems that people have hacked on locally
or that have patches from vendors installed.

   I considered using an architecture similar to that of Cygnus
'configure', where there is a single 'configure' script that reads
pieces of 'configure.in' when run.  But I didn't want to have to
distribute all of the feature tests with every package, so I settled on
having a different 'configure' made from each 'configure.in' by a
preprocessor.  That approach also offered more control and flexibility.

   I looked briefly into using the Metaconfig package, by Larry Wall,
Harlan Stenn, and Raphael Manfredi, but I decided not to for several
reasons.  The 'Configure' scripts it produces are interactive, which I
find quite inconvenient; I didn't like the ways it checked for some
features (such as library functions); I didn't know that it was still
being maintained, and the 'Configure' scripts I had seen didn't work on
many modern systems (such as System V R4 and NeXT); it wasn't very
flexible in what it could do in response to a feature's presence or
absence; I found it confusing to learn; and it was too big and complex
for my needs (I didn't realize then how much Autoconf would eventually
have to grow).

   I considered using Perl to generate my style of 'configure' scripts,
but decided that 'm4' was better suited to the job of simple textual
substitutions: it gets in the way less, because output is implicit.
Plus, everyone already has it.  (Initially I didn't rely on the GNU
extensions to 'm4'.)  Also, some of my friends at the University of
Maryland had recently been putting 'm4' front ends on several programs,
including 'tvtwm', and I was interested in trying out a new language.