Go to the first, previous, next, last section, table of contents.
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.
Go to the first, previous, next, last section, table of contents.