GNU Info

(autoconf.info)Exodus

---

Next: Leviticus Prev: Genesis Up: History

---

Enter node , (file) or (file)node

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.