Next: The GNU Build System Prev: Top Up: Top
A physicist, an engineer, and a computer scientist were discussing the
nature of God. "Surely a Physicist," said the physicist, "because
early in the Creation, God made Light; and you know, Maxwell's
equations, the dual nature of electromagnetic waves, the relativistic
consequences..." "An Engineer!," said the engineer, "because
before making Light, God split the Chaos into Land and Water; it takes a
hell of an engineer to handle that big amount of mud, and orderly
separation of solids from liquids..." The computer scientist
shouted: "And the Chaos, where do you think it was coming from, hmm?"
Autoconf is a tool for producing shell scripts that automatically
configure software source code packages to adapt to many kinds of
Posix-like systems. The configuration scripts produced by Autoconf are
independent of Autoconf when they are run, so their users do not need
to have Autoconf.
The configuration scripts produced by Autoconf require no manual user
intervention when run; they do not normally even need an argument
specifying the system type. Instead, they individually test for the
presence of each feature that the software package they are for might
need. (Before each check, they print a one-line message stating what
they are checking for, so the user doesn't get too bored while waiting
for the script to finish.) As a result, they deal well with systems
that are hybrids or customized from the more common Posix variants.
There is no need to maintain files that list the features supported by
each release of each variant of Posix.
For each software package that Autoconf is used with, it creates a
configuration script from a template file that lists the system features
that the package needs or can use. After the shell code to recognize
and respond to a system feature has been written, Autoconf allows it to
be shared by many software packages that can use (or need) that feature.
If it later turns out that the shell code needs adjustment for some
reason, it needs to be changed in only one place; all of the
configuration scripts can be regenerated automatically to take advantage
of the updated code.
Those who do not understand Autoconf are condemned to reinvent it,
poorly. The primary goal of Autoconf is making the _user's_ life
easier; making the _maintainer's_ life easier is only a secondary goal.
Put another way, the primary goal is not to make the generation of
`configure' automatic for package maintainers (although patches along
that front are welcome, since package maintainers form the user base of
Autoconf); rather, the goal is to make `configure' painless, portable,
and predictable for the end user of each "autoconfiscated" package.
And to this degree, Autoconf is highly successful at its goal -- most
complaints to the Autoconf list are about difficulties in writing
Autoconf input, and not in the behavior of the resulting `configure'.
Even packages that don't use Autoconf will generally provide a
`configure' script, and the most common complaint about these
alternative home-grown scripts is that they fail to meet one or more of
the GNU Coding Standards that users have come to expect from
Autoconf-generated `configure' scripts.
The Metaconfig package is similar in purpose to Autoconf, but the
scripts it produces require manual user intervention, which is quite
inconvenient when configuring large source trees. Unlike Metaconfig
scripts, Autoconf scripts can support cross-compiling, if some care is
taken in writing them.
Autoconf does not solve all problems related to making portable
software packages--for a more complete solution, it should be used in
concert with other GNU build tools like Automake and Libtool. These
other tools take on jobs like the creation of a portable, recursive
makefile with all of the standard targets, linking of shared libraries,
and so on. Note: The GNU Build System, for more information.
Autoconf imposes some restrictions on the names of macros used with
`#if' in C programs (Note: Preprocessor Symbol Index).
Autoconf requires GNU M4 version 1.4.5 or later in order to generate
the scripts. It uses features that some versions of M4, including GNU
M4 1.3, do not have. Autoconf works better with GNU M4 version 1.4.11
or later, though this is not required.
Note: Autoconf 1, for information about upgrading from version 1.
Note: History, for the story of Autoconf's development. Note: FAQ,
for answers to some common questions about Autoconf.
See the Autoconf web page (http://www.gnu.org/software/autoconf/)
for up-to-date information, details on the mailing lists, pointers to a
list of known bugs, etc.
Mail suggestions to the Autoconf mailing list <firstname.lastname@example.org>.
Past suggestions are archived
Mail bug reports to the Autoconf Bugs mailing list
<email@example.com>. Past bug reports are archived
If possible, first check that your bug is not already solved in
current development versions, and that it has not been reported yet.
Be sure to include all the needed information and a short
`configure.ac' that demonstrates the problem.
Autoconf's development tree is accessible via `git'; see the
Autoconf Summary (http://savannah.gnu.org/projects/autoconf/) for
details, or view the actual repository
(http://git.sv.gnu.org/gitweb/?p=autoconf.git). Anonymous CVS access
is also available, see `README' for more details. Patches relative to
the current `git' version can be sent for review to the Autoconf
Patches mailing list <firstname.lastname@example.org>. Discussions on past
patches are archived
(http://lists.gnu.org/archive/html/autoconf-patches/), and all commits
are archived in the read-only Autoconf Commit mailing list
<email@example.com>, which is also archived
Because of its mission, the Autoconf package itself includes only a
set of often-used macros that have already demonstrated their
usefulness. Nevertheless, if you wish to share your macros, or find
existing ones, see the Autoconf Macro Archive
(http://autoconf-archive.cryp.to/), which is kindly run by Peter Simons
automatically generated by info2www