Go to the first, previous, next, last section, table of contents.
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 @option{-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 Fran@,cois 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 Lance Taylor, who added support for creating a C
header file as an alternative to putting @option{-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. Fran@,cois 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 @option{--verbose} option to configure.
Noah Friedman added the @option{--autoconf-dir} 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', @option{--host}, and
@option{--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 Fran@,cois 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 test suite, because experience had shown that
Autoconf has a pronounced tendency to regress when we change it.
Again, several alpha testers gave invaluable feedback, especially Fran@,cois 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 first, previous, next, last section, table of contents.