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 I began this page late 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 (
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
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.
As I have developed configure scripts, I found these patches useful:
The new parameter ("sort" or "cat") tells autoconf how to process the generated definitions. I prefer to sort the definitions since it eases comparison of headers for different platforms. Using "cat", will generate the definitions in the order that the configure script defines them.
This introduces a minor incompatibility: generating the here-document directly causes escaped quotes in the help-text to be displayed with the spurious backslashes. Once you have converted to this macro, you will probably want to cleanup the help message text.
There is a more recent fully-patched tarball in the ftp area, which includes packaging scripts and minor updates. Since autoconf 2.13 does not support cross-compiling, most of my development uses the 2.52 versions.
Applying a patch to autoconf is problematic, due to the minefield laid by its maintainers in the form of spurious build-dependencies upon automake and libtool. So I work with a cleaned-up source tree.
Here is a list of changes for the source tree that I work with.
A few developers still use the patched 2.13 version. Here is a list of changes for the 2.13 tree.
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 configure.in 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
Cross-compiling with autoconf 2.13 is ... difficult. Because many of my programs can be cross-compiled, I changed the configure scripts for those long ago to use the autoconf 2.52 (patched). One exception is tin, whose maintainer is happy enough with 2.13.
Some packagers do not notice, and complain about "2.13" (as a
configure script has a
--version” option). I have noticed that
OpenEmbedded cites "2.13" for ncurses (seen as comments in their
build-script). The ncurses script has used "2.52 (patched)"
5.3 in 2002.
For a different viewpoint on autoconf 2.13, start here. A diffstat helps visualize the changes: here.
Occasionally some packager complains that he cannot run
autoreconf. Very little constructive discussion
configure script which I generate and deliver
with my programs is what I have tested. The script is
portable. There is no need to regenerate it, unless
someone finds an error in the script. The number of people who
want to run
autoreconf is orders of magnitude larger
than those who provide useful patches for the configure
Still, there are a few. After some feedback from one of the Debian developers, I made changes (starting in May 2010) to support packaging my patched autoconf. At the same time, I began providing the patched version as a complete tarball rather than providing only the patch.
Here are links to some relevant discussion:
Because there are no naming conflicts between any of the various configurations for different versions of autoconf (a continuing problem due to successive incompatibilities), and mine, there is less inconvenience to developers who want to investigate problems in the configure script.
Autoconf is extensible. Sometimes that idea is lost by its mainstream maintainers. But most of my work on autoconf has been in developing macros to use in my configure-scripts.
Here are some numbers to quantify that (writing late in 2014, using Debian 8's packages as a reference):
20342 16077 total lines/SLOCs 4055 lines had comments 19.9 % 895 comments are inline -4.4 % 1105 lines were blank 5.4 % 0 lines for preprocessor 0.0 % 16077 lines containing code 79.0 % 20342 total lines 100.0 % 104556 comment-chars 18.0 % 18633 nontext-comment-chars 3.2 % 25157 whitespace-chars 4.3 % 0 preprocessor-chars 0.0 % 431435 statement-chars 74.4 % 579781 total characters 100.0 % 547 tokens, average length 7.92 0.24 ratio of comment:code
50248 24483 total lines/SLOCs 23829 lines had comments 47.4 % 1302 comments are inline -2.6 % 3238 lines were blank 6.4 % 0 lines for preprocessor 0.0 % 24483 lines containing code 48.7 % 50248 total lines 100.0 % 598935 comment-chars 32.9 % 153347 nontext-comment-chars 8.4 % 169158 whitespace-chars 9.3 % 0 preprocessor-chars 0.0 % 899900 statement-chars 49.4 % 1821340 total characters 100.0 % 996 tokens, average length 8.03 0.67 ratio of comment:code
24505 13978 total lines/SLOCs 10383 lines had comments 42.4 % 2680 comments are inline -10.9 % 2824 lines were blank 11.5 % 0 lines for preprocessor 0.0 % 13978 lines containing code 57.0 % 24505 total lines 100.0 % 219205 comment-chars 26.6 % 67135 nontext-comment-chars 8.2 % 65068 whitespace-chars 7.9 % 0 preprocessor-chars 0.0 % 471960 statement-chars 57.3 % 823368 total characters 100.0 % 1595 tokens, average length 9.15 0.46 ratio of comment:code
1894 1130 total lines/SLOCs 664 lines had comments 35.1 % 37 comments are inline -2.0 % 137 lines were blank 7.2 % 0 lines for preprocessor 0.0 % 1130 lines containing code 59.7 % 1894 total lines 100.0 % 20180 comment-chars 28.7 % 2911 nontext-comment-chars 4.1 % 4915 whitespace-chars 7.0 % 0 preprocessor-chars 0.0 % 42319 statement-chars 60.2 % 70325 total characters 100.0 % 36 tokens, average length 8.00 0.48 ratio of comment:code
1770 1160 total lines/SLOCs 579 lines had comments 32.7 % 102 comments are inline -5.8 % 133 lines were blank 7.5 % 0 lines for preprocessor 0.0 % 1160 lines containing code 65.5 % 1770 total lines 100.0 % 15797 comment-chars 23.7 % 3138 nontext-comment-chars 4.7 % 4957 whitespace-chars 7.4 % 0 preprocessor-chars 0.0 % 42890 statement-chars 64.2 % 66782 total characters 100.0 % 56 tokens, average length 8.18 0.37 ratio of comment:code
3261 2687 total lines/SLOCs 587 lines had comments 18.0 % 286 comments are inline -8.8 % 273 lines were blank 8.4 % 0 lines for preprocessor 0.0 % 2687 lines containing code 82.4 % 3261 total lines 100.0 % 10943 comment-chars 11.3 % 1115 nontext-comment-chars 1.2 % 2722 whitespace-chars 2.8 % 0 preprocessor-chars 0.0 % 82137 statement-chars 84.7 % 96917 total characters 100.0 % 155 tokens, average length 8.66 0.13 ratio of comment:code
More to the point, very little of the work that I have done is
performed in the autoconf
The interested reader may start by comparing its checks for ncurses, compiler warnings, etc.
Some of the macros (and programs) which I have written work with, or around, problems with portability of other programs. Here are some topics which I will expand in this section (as separate pages, since some of the discussion is lengthy):
/usr/bin/echoor as implemented in a shell.
make, implementations which relate to my projects, as well as an overview of build-tools which I have used.
tar, implementations which relate to my projects, as well as tradeoffs for
/usr/bin/testor as implemented in a shell.
tput, beyond the scope of ncurses.