Copyright © 1997-2013,2014 by Thomas E. Dickey


autoconf is a package for creating Bourne shell scripts to configure source code packages using templates and an `m4' macro package.


Autoconf was written chiefly by David Mackenzie, with input from many people, starting in 1991. When this page was started in 1997, the most recent releases (2.12 and 2.10) were used in hundreds of programs. Like the Perl-based dist, autoconf is essentially a library of useful tests that a developer can put together to ask questions about a system to determine which features it has. Both are customizable, but dist is not as widely used. Autoconf is simpler, easier to learn.

I have been using autoconf since June 1994, when Kevin Buettner started writing a configure script for vile. I started a script for my directory editor ded. at that time, as well. Both of these scripts differ philosophically from autoconf's design. The designer of autoconf decided that there should be two ways to generate C-style definitions:

Autoconf is not design-neutral; sometimes this makes it awkward. Kevin chose a third alternative for vile, which we have kept because the first two options are unpalatable (the first because of tool limitations, and the second because it imposes unnecessary work on the maintainers, and maintaining the template is error-prone):

Since then, I've written simple configure scripts for several programs, as well as more complex scripts for a few (ncurses, tin, lynx, xterm).

Though I have been writing macros for autoconf since 1994 (prompted by Kevin Buettner's work on vile), it was not until August 1997 that I started maintaining the macros as a separate source archive. Until that point, I would simply cut/paste macros from a "good" copy into the program that I was working on. In 1997, I wrote a pair of utilities (acsplit and acmerge) which I use to maintain the macros in their present form, resynchronizing them as needed as I work on each program. I refer to the common archive as "my-autoconf".

At one point (early in 1998) I was discussing with Richard Stallman the possibility of becoming autoconf maintainer, There is an assignment on file which "Assigns past and future changes", but because the paperwork is incomplete (which the file does not note), that assignment has no effect. In particular, none of my autoconf-related patches are copyrighted by the Free Software Foundation.


I find these patches useful:

Occasionally someone asks why I use autoconf 2.13 (actually the question should be why I maintain configure scripts which are compatible with 2.13). The autoconf group, rather than focusing on making a reliable product, is using ongoing development as a basis for experimentation. With some care, it is possible to construct files which are compatible between 2.13 and 2.5x. However, the standard response to reports of incompatibilities between the two is to blame 2.13 for "bugs" (ostensibly for quoting issues, but in fact on any issue without further analysis). Here is a recap of more recent autoconf versions and release dates:

Generally the changelog of autoconf does not reflect the issues (serious defects and incompatibilities) reported on their mailing list.

As an example, consider "autoreconf". The reason for this tool is to repair the interfaces between autoconf and automake (which break on a regular basis) by regenerating the output from autoconf. Fortunately, I do not use automake (a monolithic perl script much larger than the make program). So I have no use for autoreconf.