File: autoconf.info,  Node: Introduction,  Next: The GNU Build System,  Prev: Top.php">Top,  Up: Top.php">Top

1 Introduction
**************

 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?"

                                                            --Anonymous

   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 (*note (standards)Configuration::) 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.8 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.16
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 (https://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 .
Past suggestions are archived
(https://lists.gnu.org/archive/html/autoconf/).

   Mail bug reports to the Autoconf Bugs mailing list
.  Past bug reports are archived
(https://lists.gnu.org/archive/html/bug-autoconf/).

   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 (https://savannah.gnu.org/projects/autoconf/) for details, or
view the actual repository
(https://git.savannah.gnu.org/cgit/autoconf.git).  Patches relative to
the current ‘git’ version can be sent for review to the Autoconf Patches
mailing list , with discussion on prior
patches archived (https://lists.gnu.org/archive/html/autoconf-patches/);
and all commits are posted in the read-only Autoconf Commit mailing list
, which is also archived
(https://lists.gnu.org/archive/html/autoconf-commit/).

   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
(https://www.gnu.org/software/autoconf-archive/), which is kindly run by
Peter Simons .