http://invisible-island.net/
Copyright © 1997-2020,2022 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 (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.
As I have developed configure scripts, I found these patches useful:
971222 simplify the way we generate the config.h file. This patch adds a parameter to AC_OUTPUT that tells it to use the definitions that it has built up to directly substitute into the template header, which can then be as simple as the single line
@DEFS@
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.
971222-emx a patch from Juan Jose Garcia Ripoll <worm@arrakis.es>, originally for autoconf 2.10, for an OS/2 EMX-specific version of autoconf.
971230 my own patch, for working around machines with limited environment space. AC_DIVERT_HELP splits long help messages into smaller pieces, which are emitted as a series of here-documents rather than attempt to keep their text in an environment variable. I use this macro to replace logic in autoconf's AC_ARG_ENABLE and AC_ARG_WITH, so it works without requiring you to change your configure.in or aclocal.m4 files.
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.
autoconf 2.13 20030927 This is the most recent version of the autoconf 2.13 patch.
There is a more recent fully-patched tarball in the archive 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.
autoconf 2.13 20020210 EMX This is the most recent version of the autoconf 2.13 patch for EMX.
autoconf 2.52 20030208 This is a resync of the patch (not EMX) against autoconf 2.52 (lightly tested: autoconf 2.5x introduces a number of incompatibilities with autoconf 2.13). The patch also includes some fixes for minor bugs which were reported/ignored on the autoconf mailing list. Finally, it repairs some of the intentional incompatibilites.
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.
autoconf 2.57 20030810 Even more lightly tested -- having noticed some new autoconf defects as I resync'd this patch, but unrelated to the patch.
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 autoconf versions which followed over the next few years:
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 in any of my own projects. It is a perl
script much larger than the make program. To
illustrate, here is a listing showing the sizes of Debian
packages for those, and related programs:
-rw-r--r-- 1 root root 338182 Mar 26 2016 autoconf_2.69-10_all.deb -rw-r--r-- 1 root root 341334 Aug 20 2017 autoconf_2.69-11_all.deb -rw-r--r-- 1 root root 340460 Aug 31 2014 autoconf_2.69-8_all.deb -rw-r--r-- 1 root root 724498 Aug 11 2016 automake_1%3a1.14.1-4+deb8u1_all.deb -rw-r--r-- 1 root root 732812 Jan 25 2017 automake_1%3a1.15-6_all.deb -rw-r--r-- 1 root root 771100 Nov 5 2018 automake_1%3a1.16.1-4_all.deb -rw-r--r-- 1 root root 189994 Oct 14 2014 libtool_2.4.2-1.11_all.deb -rw-r--r-- 1 root root 546944 Aug 28 13:49 libtool_2.4.6-11_all.deb -rw-r--r-- 1 root root 545256 Aug 20 2016 libtool_2.4.6-2_all.deb -rw-r--r-- 1 root root 546792 Jan 28 2019 libtool_2.4.6-9_all.deb -rw-r--r-- 1 root root 349096 Jan 17 2015 make_4.0-8.1_amd64.deb -rw-r--r-- 1 root root 302456 Feb 7 2017 make_4.1-9.1_amd64.deb -rw-r--r-- 1 root root 340748 Aug 4 2018 make_4.2.1-1.2_amd64.deb
So I have no use for autoreconf.
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 hint, the 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)” since ncurses 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
ensues.
The 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
script.
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.
I keep those macros in a collection which I called my-autoconf.
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/echo or as implemented in a shell.make, implementations which relate to my
projects, as well as an overview of build-tools which I have
used.cpio and pax./usr/bin/test or as implemented in a shell.tput, beyond the scope of ncurses.