View source for GNU Autotools

{{Short description|Software build toolset from GNU}}
{{Refimprove|date=September 2009}}
{{Infobox software
| title = GNU Autotools
| logo = Heckert GNU white.svg
| logo alt = GNU logo
| logo size = 256px
| author = Community 
| developer = [[Free Software Foundation]]
| released = <!-- release date? -->
| latest release version = Multiple 
| programming language = [[M4 (computer language)]], [[C (programming language)|C]]
| operating system = [[Cross-platform]]
| platform = [[GNU]] and others
| included with = [[GNU Operating System]]
| language = English
| license = [[GNU General Public License]] version 2
| website = {{URL|https://www.gnu.org/software/software.html}}
}}

The '''GNU Autotools''', also known as the '''GNU Build System''', is a suite of [[build automation]] [[programming tool|tools]] designed to support building [[source code]] and [[Software package (installation)|packaging]] the resulting binaries. It supports building a [[codebase]] for multiple target systems without customizing or modifying the [[source code|code]]. It is available on many [[Linux distribution]]s and [[Unix-like]] environments. 

Autotools is part of the [[GNU toolchain]] and is widely used in many [[free software]] and [[Open-source license|open source]] packages.  Its component tools are [[free software]], licensed under the [[GNU General Public License]] with special license exceptions<ref name="autoconf-except">{{cite web |url=http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=COPYING.EXCEPTION;h=469583528592cd69ac0847803b443849dcc9b1eb;hb=HEAD |archive-url=https://web.archive.org/web/20110721073834/http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=COPYING.EXCEPTION;h=469583528592cd69ac0847803b443849dcc9b1eb;hb=HEAD |url-status=dead |archive-date=2011-07-21 |title=Savannah Git Hosting - autoconf.git/blob - COPYING.EXCEPTION |website=Git.savannah.gnu.org |access-date=2016-04-01 }}</ref><ref name="libtool-hacking">{{cite web|url=http://git.savannah.gnu.org/cgit/libtool.git/tree/HACKING?id=9c9cde2c95f3f04f48288e1911038249d5ac424b |title=libtool.git - GNU Libtool |website=Git.savannah.gnu.org |date=2005-01-08 |access-date=2016-04-01}}</ref> permitting its use with [[proprietary software]].

== Motivation ==

It can be difficult to make a software program portable. Compilers differ from system to system. Certain library functions are missing on some systems. Compiler files (such as C headers) may have different names. Shared libraries may be compiled and installed in different ways. One way to handle platform differences is to write conditionally compiled code (i.e. via <code>#ifdef</code>), but because of the wide variety of build environments, this approach quickly becomes unmanageable. Autotools is designed to address this problem more manageably.

== Components ==
Autotools consists of the [[GNU]] utilities [[Autoconf]], [[Automake]], and [[Libtool]].<ref>{{cite web|url=https://autotoolset.sourceforge.net/tutorial.html#SEC40 |title=Learning the GNU development tools |website=Autotoolset.sourceforge.net |access-date=2016-04-01}}</ref> Other related tools include GNU [[make (software)|make]], GNU [[gettext]], [[pkg-config]], and the [[GNU Compiler Collection]] (GCC).

== Usage ==

[[File:Autoconf-automake-process.svg|thumb|450px|right|Flow diagram of Autotools tools.]]

Autotools assists with sharing [[cross-platform]] software with a relatively broad user community. It facilitates sharing the source code by providing relatively robust cross-platform build support so that consumers can build the software themselves. Generally, the source code is distributed with a [[configure script|script]], named ''configure'', that has no dependencies other than a [[Bourne shell|Bourne-compatible]] [[Unix shells|shell]]. Autotools need not be available. The consumer runs <code>configure</code> which generates various files including a ''Makefile'' which the consumer uses by running <code>make</code>.<ref>{{cite web|url=https://www.gnu.org/software/automake/manual/html_node/GNU-Build-System.html |title=automake: GNU Build System |website=Gnu.org |date=2014-12-31 |access-date=2016-04-01}}</ref><ref>{{cite web|url=http://airs.com/ian/configure/configure_1.html#SEC5 |title=The GNU configure and build system - Introduction |website=Airs.com |date=1998-07-01 |access-date=2016-04-01}}</ref>

Autotools can be used both for building native programs on the build machine and also for [[cross-compiling]] to other architectures.<ref>{{cite web|url=http://sources.redhat.com/autobook/autobook/autobook_258.html |title=Cross Compilation with GNU Autotools |access-date=September 24, 2008 |url-status=dead |archive-url=https://web.archive.org/web/20081013213002/http://sources.redhat.com/autobook/autobook/autobook_258.html |archive-date=October 13, 2008 }}</ref>

Cross-compiling software to run on a Windows host from a Linux or other Unix-like build system is also possible, using MinGW, however native compilation is often desirable on operating systems (such as the [[Microsoft Windows]] family of systems) that cannot run Bourne shell scripts on their own.  This makes building such software on the Windows operating system a bit harder than on a [[Unix-like]] system which provides the Bourne shell as a standard component.  One can install the [[Cygwin]] or [[MSYS]] system on top of Windows to provide a [[Unix-like]] [[compatibility layer]], though, allowing [[configure (computing)|configure]] scripts to run.  Cygwin also provides the [[GNU Compiler Collection]], [[GNU make]], and other software that provides a nearly complete Unix-like system within Windows; MSYS also provides GNU make and other tools designed to work with the [[MinGW]] version of GCC.

A consumer can re-generate the configure script which might be necessary if they amend the source code. In this case, they need to have Autotools installed.

The autoconf-generated configure script can be slow because it executes programs such as a C compiler multiple times to test whether various libraries, header files, and language features are present. This particularly affects [[Cygwin]], which, due to its lack of a native [[Fork (operating system)|fork system call]], may execute configure scripts considerably slower than on [[Linux]].<ref>{{cite web|url=http://cygwin.com/ml/cygwin/2005-04/msg00703.html |title=Robert Ögren - Slow shell script execution on Cygwin |website=Cygwin.com |access-date=2016-04-01}}</ref>

==Criticism==
In his column for ''[[ACM Queue]]'', [[FreeBSD]] developer [[Poul-Henning Kamp]] criticized the GNU Build System:<ref>{{cite journal |first=Poul-Henning |last=Kamp |year=2012 |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>

{{quote|The idea is that the configure script performs approximately 200 automated tests, so that the user is not burdened with configuring libtool manually. This is a horribly bad idea, already much criticized back in the 1980s when it appeared, as it allows source code to pretend to be portable behind the veneer of the configure script, rather than actually having the quality of portability to begin with. It is a travesty that the configure idea survived.}}

Kamp sketches the history of the build system in the portability problems inherent in the [[History of Unix#1980s|multitude of 1980s Unix variants]], and bemoans the need for such build systems to exist:

{{quote|the 31,085 lines of configure for libtool still check if {{mono|[[stat (system call)|<sys/stat.h>]]}} and {{mono|[[C standard library|<stdlib.h>]]}} exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code.}}

Although critics of the Autotools frequently advocate for alternatives that provide greater simplicity to their users, some have argued that this is not necessarily a good thing. John Calcote, author<ref>{{cite web|url=https://www.penguinrandomhouse.ca/books/600402/autotools-2nd-edition-by-john-calcote/9781593279721 |title=Autotools, 2nd Edition by John Calcote {{!}} Penguin Random House Canada |access-date=January 22, 2021}}</ref> of the ''Autotools, 2nd Edition: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool'', opined:<ref>{{cite web|url=https://lists.gnu.org/archive/html/automake/2021-01/msg00013.html |title=Re: Future plans for Autotools |access-date=January 22, 2021}}</ref>

{{quote|
The Autotools are actually more transparent than any other build tools out there. All these other tools' (cmake, maven, etc) - that purport to be so much simpler because they insulate the user from the underlying details of the build process - these tool's primary failure is that this very insulation keeps users from being able to make the changes they need to accomplish their unique project-specific build goals.

Anyone who has nothing but good things to say about this aspect of cmake, maven, gradle, or whatever, has simply not worked on a project that requires them to move far enough away from the defaults. I've used them all and I've spent hours in frustration trying to determine how to work around the shortcomings of some "do-all" (except what I want) tool function. This is simply not an issue with the Autotools. As someone mentioned earlier in this thread, you can drop shell script into a configure.ac file, and make script into a Makefile.am file. That is the very definition of transparency. No other tool in existence allows this level of flexibility.}}

== See also ==
{{portal|Free and open-source software}}

* [[List of build automation software]]

==References==
{{Reflist}}

==External links==
* {{Official website|https://www.gnu.org/software/software.html}}

{{DEFAULTSORT:Gnu Build System}}
[[Category:Build automation]]
[[Category:Compiling tools]]
[[Category:GNU Project software|Build system]]
[[Category:Software using the GNU General Public License]]
[[Category:Unix programming tools]]