Editing Autoconf

{{Short description|Autotools configure script generator}}
{{Distinguish|Autoconfig}}
{{Infobox software
| name                   = Autoconf
| title                  = 
| logo                   = Heckert GNU white.svg
| logo size              = 100px
| screenshot             = <!-- [[File: ]] -->
| caption                = 
| collapsible            = 
| author                 = David Mackenzie
| developer              = [[GNU Project]]
| released               = 1991<!-- {{Start date|YYYY|MM|DD|df=yes/no}} -->
| discontinued           = 
| latest release version = {{wikidata|property|preferred|references|edit|P348|P548=Q2804309}}
| latest release date    = {{Start date and age|{{wikidata|qualifier|preferred|single|P348|P548=Q2804309|P577}}|df=yes}}
| latest preview version = 
| latest preview date    = <!-- {{Start date and age|YYYY|MM|DD|df=yes/no}} -->
| programming language   = [[Perl]]
| operating system       = [[Cross-platform]]
| platform               = 
| size                   = 
| language               = 
| status                 = 
| genre                  = [[Programming tool]]
| license                = [[GNU General Public License|GNU GPL]]
| website                = {{URL|https://www.gnu.org/software/autoconf/}}
}}

'''GNU Autoconf''' is a [[software development tool]] for generating a [[configure script]] that in turn generates files for building a [[codebase]] and for packaging or installing the resulting [[computer file|files]]. Autoconf is part of the [[GNU Build System]] {{endash}} along with [[Automake]], [[GNU Libtool|Libtool]], Autoheader and other tools.

Autoconf is agnostic about the programming language of the codebase to build. None-the-less, it is primarily used with [[C (programming language)|C]], [[C++]], [[Fortran]], [[Erlang (programming language)|Erlang]], or [[Objective-C]].

A configure script configures a software package for [[installation (computer programs)|installation]] on a particular target system.  After running a series of tests on the target system, the configure script generates [[header files]] and a [[makefile]] from templates, thus customizing the software package for the target system. 

== Usage overview ==

[[File:Autoconf-automake-process.svg|thumb|450px|right|Flow diagram of Autoconf and [[Automake]]. Note that "configure.ac" was named "configure.in" in early versions of Autoconf.]]

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 "configure.ac".  A library of pre-defined m4 [[macro (computer science)|macros]] is available to describe common configure script instructions.  Autoconf transforms the instructions in "configure.ac" into a portable configure script.
The system that will be doing the building need not have Autoconf installed: Autoconf is needed only to build the configure script, that is usually shipped with the software.

== History ==
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]].

== Approach ==
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 [[Porting|portability]] is to test for [[feature (software design)|feature]]s, not for [[Software versioning|versions]]. For example, the native C compiler on SunOS 4 did not support [[C (programming language)|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 [[system administrator|administrator]]s 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 provides extensive documentation around the non-portability of many POSIX shell constructs to older shells and bugs therein. It also provides M4SH, a macro-based replacement for shell syntax.<ref>{{cite web |title=Portable Shell |url=https://www.gnu.org/software/autoconf/manual/html_node/Portable-Shell.html |website=Autoconf |access-date=20 January 2020}}</ref>

== Behavior ==
Autoconf generates a <code>configure</code> script based on the contents of a <code>configure.ac</code> file, which characterizes a particular body of source code.  The <code>configure</code> script, when run, scans the build environment and generates a subordinate <code>config.status</code> script which, in turn, converts other input files and most commonly <code>Makefile.in</code> into output files (<code>Makefile</code>), which are appropriate for that build environment.  Finally, the <code>make</code> program uses <code>Makefile</code> to generate executable programs from source code.

The complexity of Autotools reflects the variety of circumstances under which a body of source code may be built.

* If a source code file is changed then it suffices to re-run <code>make</code>, which only re-compiles that part of the body of the source code affected by the change.
* If a <code>.in</code> file has changed then it suffices to re-run <code>config.status</code> and <code>make</code>.
* If the body of source code is copied to another computer then it is sufficient to re-run <code>configure</code> (which runs <code>config.status</code>) and <code>make</code>.  (For this reason source code using Autotools is normally distributed without the files that <code>configure</code> generates.)
* If the body of source code is changed more fundamentally, then <code>configure.ac</code> and the <code>.in</code> files need to be changed and all subsequent steps also followed.

To process files, autoconf uses the GNU implementation of the [[m4 (computer language)|m4]] macro system.

Autoconf comes with several auxiliary programs such as <code>autoheader</code>, which is used to help manage [[C (programming language)|C]] [[header file]]s; <code>autoscan</code>, which can create an initial input file for Autoconf; and <code>ifnames</code>, which can list C pre-processor identifiers used in the program.

==Criticism==
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 ''configure.ac'' scripts. In particular, often cited weak points of Autoconf are:
* General complexity of used architecture, most projects use multiple repetitions.<ref name="kde">{{cite web
|title = Why the KDE project switched to CMake -- and how
|first = Alexander
|last = Neundorf
|date = 2006-06-21
|url = https://lwn.net/Articles/188693/
}}</ref><ref name="lost-bazaar">{{cite journal
|first=Poul-Henning
|last=Kamp
|date=2012-08-15
|journal=ACM Queue
|volume=10
|issue=8
|title=A Generation Lost in the Bazaar
|pages=20–23
|doi=10.1145/2346916.2349257
|s2cid=11656592
|doi-access=free
}}</ref>
* Some people think that 'configure' scripts generated by Autoconf provide only manual-driven command-line interface without any standardization.<ref name="stop-insanity"/> While it is true that some developers do not respect common conventions, such conventions do exist and are widely used.<ref name="gnu-coding">{{cite web
|title = GNU Coding Standards
|url = https://www.gnu.org/prep/standards/standards.html
}}</ref>
* m4 is unusual and unknown to many developers. Developers will need to learn it to extend Autoconf with non-standard checks.<ref name="stop-insanity">{{cite web
|first = Andrew
|last = McCall
|title = Stop the autoconf insanity! Why we need a new build system
|url = http://freshmeat.net/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system
|date = 2003-06-21
|archive-url=https://web.archive.org/web/20090707114247/http://freshmeat.net/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system
|archive-date=2009-07-07
|url-status=dead
}}</ref><ref name="autocrap">{{cite web
 |title        = Did you call them ''autocrap'' tools?
 |first        = Poul-Henning
 |last         = Kamp
 |date         = 2010-04-20
 |url          = https://varnish-cache.org/docs/5.0/phk/autocrap.html
 |access-date  = 2017-08-16
 |archive-url  = https://web.archive.org/web/20170911030645/http://varnish-cache.org/docs/5.0/phk/autocrap.html
 |archive-date = 2017-09-11
 |url-status     = dead
}}</ref>
* Weak backward and forward compatibility requires a wrapper script.<ref name="autoconf 2.13">{{cite web
|first = Thomas 
|last = Dickey 
|title = why i still use autoconf 2.13
|url = http://invisible-island.net/autoconf/autoconf.html
}}</ref>
* Autoconf-generated scripts are usually large and rather complex. Although they produce extensive logging, debugging them can still be difficult.

Due to these limitations, several projects that used GNU Build System switched to different build systems, such as [[CMake]] and [[SCons]].<ref name="kde"/><ref name="blender">{{Cite web |url=http://www.blender.org/development/release-logs/blender-233/build-systems/ |title=Blender.org - Build systems |access-date=2009-06-10 |archive-url=https://web.archive.org/web/20081202083359/http://www.blender.org/development/release-logs/blender-233/build-systems/ |archive-date=2008-12-02 |url-status=dead }}</ref>

==See also==
{{Portal|Free and open-source software}}
* {{Annotated link|CMake}}
* {{Annotated link|Meson (software)|Meson}}
* {{Annotated link|pkg-config}}

==References==
{{Reflist}}

== External links ==

* {{official website}}
* [https://www.gnu.org/software/ac-archive/ GNU Autoconf macro archive]
* [http://sources.redhat.com/autobook/ ''The Goat Book'' homepage (aka the Autobook)] {{Webarchive|url=https://web.archive.org/web/20101220095404/http://sources.redhat.com/autobook/ |date=2010-12-20 }}
* [https://web.archive.org/web/20041013190022/http://www.openismus.com/documents/linux/automake/automake.shtml Using Automake and Autoconf with C++]
* [https://web.archive.org/web/20060413182543/http://www.openismus.com/documents/linux/using_libraries/using_libraries.shtml Using C/C++ libraries with Automake and Autoconf].
* [http://autotoolset.sourceforge.net Autotoolset home page]
* [https://web.archive.org/web/20140816060326/http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool Autotools: A practitioner's guide to Autoconf, Automake and Libtool]
* [https://autotools.info/ Autotools Mythbuster]
{{GNU}}

[[Category:Build automation]]
[[Category:Computer configuration]]
[[Category:Cross-platform free software]]
[[Category:Free computer libraries]]
[[Category:GNU Project software]]

[[de:GNU Build System#GNU Autoconf]]