Go to the previous, next section.
You may be wondering, Why was Autoconf originally written? How did it get into its present form? (Why does it look like gorilla spit?) If you're not wondering, then this chapter contains no information useful to you, and you might as well skip it. If you are wondering, then let there be light...
In June 1991 I was maintaining many of the GNU utilities for the Free
Software Foundation. As they were ported to more platforms and more
programs were added, the number of `-D' options that users had to
select in the `Makefile' (around 20) became burdensome. Especially
for me--I had to test each new release on a bunch of different systems.
So I wrote a little shell script to guess some of the correct settings
for the fileutils package, and released it as part of fileutils 2.0.
That configure script worked well enough that the next month I
adapted it (by hand) to create similar configure scripts for
several other GNU utilities packages. Brian Berliner also adapted one
of my scripts for his CVS revision control system.
Later that summer, I learned that Richard Stallman and Richard Pixley
were developing similar scripts to use in the GNU compiler tools; so I
adapted my configure scripts to support their evolving interface:
using the file name `Makefile.in' as the templates; adding
`+srcdir', the first option (of many); and creating
`config.status' files.
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.
Since my configure scripts determine the system's capabilities
automatically, with no interactive user intervention, I decided to call
the program that generates them Autoconfig. But with a version number
tacked on, that name would be too long for old UNIX file systems, so
I shortened it to Autoconf.
In the fall of 1991 I called together a group of fellow questers after
the Holy Grail of portability (er, that is, alpha testers) to give me
feedback as I encapsulated pieces of my handwritten scripts in m4
macros and continued to add features and improve the techniques used in
the checks. Prominent among the testers were
Pinard, who came up with the idea of making an `autoconf' shell
script to run m4 and check for unresolved macro calls; Richard
Pixley, who suggested running the compiler instead of searching the file
system to find include files and symbols, for more accurate results;
Karl Berry, who got Autoconf to configure TeX and added the
macro index to the documentation; and Ian Taylor, who added support for
creating a C header file as an alternative to putting `-D' options
in a `Makefile', so he could use Autoconf for his UUCP package. The
alpha testers cheerfully adjusted their files again and again as the
names and calling conventions of the Autoconf macros changed from
release to release. They all contributed many specific checks, great
ideas, and bug fixes.
In July 1992, after months of alpha testing, I released Autoconf 1.0,
and converted many GNU packages to use it. I was surprised by how
positive the reaction to it was. More people started using it than I
could keep track of, including people working on software that wasn't
part of the GNU Project (such as TCL, FSP, and Kerberos V5).
Autoconf continued to improve rapidly, as many people using the
configure scripts reported problems they encountered.
Autoconf turned out to be a good torture test for m4
implementations. UNIX m4 started to dump core because of the
length of the macros that Autoconf defined, and several bugs showed up
in GNU m4 as well. Eventually, we realized that we needed to use
some features that only GNU m4 has. 4.3BSD m4, in
particular, has an impoverished set of builtin macros; the System V
version is better, but still doesn't provide everything we need.
More development occurred as people put Autoconf under more stresses
(and to uses I hadn't anticipated). Karl Berry added checks for X11.
david zuhn contributed C++ support.
Pinard made it diagnose invalid arguments. Jim Blandy bravely coerced
it into configuring GNU Emacs, laying the groundwork for several later
improvements. Roland McGrath got it to configure the GNU C Library,
wrote the autoheader script to automate the creation of C header
file templates, and added a `--verbose' option to configure.
Noah Friedman added the `--macrodir' option and AC_MACRODIR
environment variable. (He also coined the term autoconfiscate to
mean "adapt a software package to use Autoconf".) Roland and Noah
improved the quoting protection in AC_DEFINE and fixed many bugs,
especially when I got sick of dealing with portability problems from
February through June, 1993.
A long wish list for major features had accumulated, and the effect of
several years of patching by various people had left some residual
cruft. In April 1994, while working for Cygnus Support, I began a major
revision of Autoconf. I added most of the features of the Cygnus
configure that Autoconf had lacked, largely by adapting the
relevant parts of Cygnus configure with the help of david zuhn
and Ken Raeburn. These features include support for using
`config.sub', `config.guess', `--host', and
`--target'; making links to files; and running configure
scripts in subdirectories. Adding these features enabled Ken to convert
GNU as, and Rob Savoye to convert DejaGNU, to using Autoconf.
I added more features in response to other peoples' requests. Many
people had asked for configure scripts to share the results of
the checks between runs, because (particularly when configuring a large
source tree, like Cygnus does) they were frustratingly slow. Mike
Haertel suggested adding site-specific initialization scripts. People
distributing software that had to unpack on MS-DOS asked for a way to
override the `.in' extension on the file names, which produced file
names like `config.h.in' containing two dots. Jim Avera did an
extensive examination of the problems with quoting in AC_DEFINE
and AC_SUBST; his insights led to significant improvements.
Richard Stallman asked that compiler output be sent to `config.log'
instead of `/dev/null', to help people debug the Emacs
configure script.
I made some other changes because of my dissatisfaction with the quality
of the program. I made the messages showing results of the checks less
ambiguous, always printing a result. I regularized the names of the
macros and cleaned up coding style inconsistencies. I added some
auxiliary utilities that I had developed to help convert source code
packages to use Autoconf. With the help of
Pinard, I made the macros not interrupt each others' messages.
(That feature revealed some performance bottlenecks in GNU m4,
which he hastily corrected!)
I reorganized the documentation around problems people want to solve.
And I began a testsuite, because experience
had shown that Autoconf has a pronounced tendency to regress when we
change it.
Again, several alpha testers gave invaluable feedback, especially Pinard, Jim Meyering, Karl Berry, Rob Savoye, Ken Raeburn, and Mark Eichin.
Finally, version 2.0 was ready. And there was much rejoicing. (And I have free time again. I think. Yeah, right.)
Go to the previous, next section.