The Full Wiki

Autoconf: Wikis


Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.


From Wikipedia, the free encyclopedia

Heckert GNU white.svg
Developer(s) The GNU Project
Stable release 2.65 / November 21, 2009; 3 month(s) ago (2009-11-21)
Operating system Cross-platform
Type Programming tool
License GNU GPL
Flow diagram of autoconf and automake. Note that "" was named "" in early versions of autoconf.

GNU Autoconf is a tool for producing configure scripts for C, C++, Fortran 77, Fortran, Erlang, Objective C software on Unix-like computer systems. Configure scripts inspect a user's computer system and configure the software package prior to it being installed. After running a series of automated tests, a configure script generates customised header files and a makefile from pre-written templates. These customised files adapt the software and its installation process to suit the user's system. Together with Automake and Libtool, Autoconf forms the GNU build system. It comprises several other tools, notably Autoheader.


Usage overview

The developer specifies the desired behaviour of the configure script by writing a list of instructions in the GNU m4 language in a file called "". A library of pre-defined m4 macros is available to describe common configure script instructions. Autoconf transforms the instructions in "" into a portable configure script.

Advertisements format

The GNU Autoconf manual suggests the following format for the file:

Autoconf requirements
The AC_PREREQ(version) macro can be used to ensure that a recent enough version of the autoconf program is available to process the file
AC_INIT(package, version, bug-report-address)
This macro is required in every file. It specifies the name and version of the software package for which to generate a configure script and the email address of the developer.
information on the package
checks for programs
checks for libraries
checks for header files
checks for types
checks for structures
checks for compiler characteristics
checks for library functions
checks for system services


Autoconf was begun in the summer of 1991 by David Mackenzie to support his work at the Free Software Foundation. In the subsequent years it grew to include enhancements from a variety of authors and became the most widely used build configuration system for writing portable free or open-source software.


Autoconf is similar to the Metaconfig package used by Perl. The imake system formerly used by the X Window System (up to X11R6.9) is closely related, but has a different philosophy.

The Autoconf approach to portability is to test for features, not for versions. For example, the native C compiler on SunOS 4 did not support ISO C. However, it is possible for the user or administrator to have installed an ISO C-compliant compiler. A pure version-based approach would not detect the presence of the ISO C compiler, but a feature-testing approach would be able to discover the ISO C compiler the user had installed. The rationale of this approach is to gain the following advantages:

  • the configure script can get reasonable results on newer or unknown systems
  • it allows administrators to customize their machines and have the configure script take advantage of the customizations
  • there is no need to keep track of minute details of versions, patch numbers, etc., to figure out whether a particular feature is supported or not


Autoconf is an old and mature product that, when properly used, provides a very simple interface even in complex cross-compilation scenarios. However there is some criticism that states that Autoconf uses dated technologies, has a lot of legacy restrictions, and complicates simple scenarios unnecessarily for the author of scripts. In particular, often cited weak points of Autoconf are:

  • Autoconf generated scripts are non-portable and do not run in some Bourn- compatible shells.
  • General complexity of used architecture, most projects use multiple repetitions[1].
  • Generated 'configure' is written in Unix shell and thus Makefile generation is slow. Some projects, such as KDE, tried to work around this issue by introducing distinct Makefile generators written in other languages.[1]
  • Generated 'configure' uses only manual-driven command-line interface without any standardization.[2]
  • M4's behavior is cryptic and thus hard to debug.[2]
  • Weak backward and forward compatibility.[citation needed]
  • Cannot be used when building under Mac OS X using Xcode, or under Windows using Visual C++.
  • Autoconf-generated scripts are large and cryptic, making debugging and hand tuning difficult.
  • Autoconf makes it hard to port software to exotic architectures as it keeps a list of supported architecture in the config.sub file distributed with each software package, and will not run for an architecture which is not listed.

Due to these limitations, some projects that used GNU Build System started to switch to other build systems:


See also

External links


Got something to say? Make a comment.
Your name
Your email address