Building (compiling) is the process of creating standalone program products from source code. For some interpreted languages, the source code is usually the final product, so the build process is not involved. Thus, the term is usually applied to compiled languages like C, C++, etc. Specific build tools are designed for certain languages. During a single build process, multiple invocations of compilers, linkers, and other commands may be needed. Therefore, for a large project with many source files, manual control of this process is quite cumbersome, necessitating a set of "automatic build software" to help manage it. Although for developers using an IDE, building is just a matter of clicking a button, understanding the underlying principles is more beneficial for those seeking to excel.
There are many existing build software tools, each with different designs. Some build systems use an all-in-one step mode, completing the build with a single command; others require step-by-step operations: one command to check the system environment, modify compilation behavior, and generate build control files; another command to perform the actual compilation and linking based on the build control files. Common build combinations we use include configure+make, cmake+make, qmake+make, meson+ninja, etc. The combination of configure+make usually represents the GNU build system.
The GNU build system is divided into two parts: GNU make and GNU autotools. Make is a POSIX standard build tool with different implementations across various systems (the one we use in the GNU system is naturally GNU make). Hence, many build systems use make as the backend. GNU autotools include multiple components, with the main parts being GNU autoconf and GNU automake, aiming to create configure scripts. Since configure scripts are executed using the POSIX standard shell interpreter, once created, the operating system does not need to have GNU autotools installed to complete the build on any POSIX-compliant operating system.
Make
Make is a POSIX standard build tool, and its control file is the Makefile. A Makefile uses recipe-like syntax, where each recipe requires a "target," "prerequisites," and "commands" to form a complete part. Make can automatically detect changes in source files, so there’s no need to redo targets that haven’t changed in subsequent builds. The targets in the Makefile are also the commands for make; simply enter "make " to build the corresponding file. Some make targets can be set as "phony targets" (e.g., install, clean), which do not produce actual files but serve as commands or intermediate steps. These targets need to be specially marked to avoid confusion with actual files of the same name, ensuring make executes the corresponding commands.
Configure
Due to differences between operating system platforms, a Makefile may not always be compatible. Initially, the practice was to write a separate Makefile for each platform. In 1991, David J. MacKenzie handwrote a small shell script to detect platform characteristics and dynamically generate Makefiles for his program on 20 platforms, naming this script configure. Over time, it was adopted by other projects. MacKenzie later combined and packaged the frequently copied and pasted sections from various configure scripts into autoconf (see below). Nowadays, the configure scripts we see are usually generated by autoconf, though it’s rare for developers to write them manually anymore.
Configure is a shell script that checks whether the operating system environment meets compilation requirements and then generates Makefile and config.h files based on template files Makefile.in and config.h.in. Makefile is for make, while config.h contains build options for the C compiler’s preprocessing (included in C source code; once configure completes, make can use these options during compilation). Additionally, configure can accept runtime parameters to modify some compilation behaviors by generating different output files.
Autoconf
Autoconf generates configure scripts. It comprises various shell code snippets and uses the m4 macro processing language. A "macro" allows a (usually complex) original text to be represented by a shorthand (macro), which m4 then automatically expands into the original text.
Autoconf uses the configure.ac file as input. By adding autoconf-provided macros to this file and executing the autoconf command, configure.ac is expanded into the actual configure script. Autoconf actually uses an enhanced version of m4, autom4te, which includes caching functionality to prevent repeated execution of the same sections.
Autoheader
Autoheader automatically generates the config.h.in template file from configure.ac. Autoheader is included in the autoconf package.
Automake
Automake generates Makefile.in template files by writing Makefile.am, ensuring the final Makefile complies with GNU standards. Automake is similar to standalone make in expressing the transformation relationship between source and target files, but it is stricter, requiring the type of files to be specified. Additionally, since automake needs to interact with autoconf, it’s more restrictive compared to standalone make, which is not limited by programming language or platform.
Automake also reads configure.ac to obtain project information. Related functionalities of automake must be used in configure.ac, which requires another file, aclocal.m4, containing automake macros. The aclocal.m4 file is generated using the aclocal command, which is part of the automake package. If automake is used in a project, execute aclocal first; autoconf and automake can be executed as needed. (Refer to manuals for the execution order of other commands.)
Autoreconf
If the above sequence seems confusing, autoreconf can save the day. Autoreconf automatically executes all necessary commands to generate configure scripts, requiring only configure.ac and Makefile.am. It not only runs autoconf and automake but also supports many other commands. According to the manual, autoreconf runs autoconf, autoheader, aclocal, automake, libtoolize, intltoolize, gtkdocize, and autopoint when needed. Simply place the corresponding macros in configure.ac, and then run autoreconf.
Some software uses a script named bootstrap or autogen.sh to combine command sequences, doing similar work to autoreconf. With autoreconf available, there’s no need to create other scripts.
Although autoreconf automates command execution, it doesn't mean you can skimp on writing configuration files. Understanding autoconf and automake is still crucial. Autoreconf is included in the autoconf package.
Autoscan
Autoscan automatically checks source code and generates configure.ac (output file named configure.scan), which must be manually reviewed and modified before renaming to configure.ac for autoconf. The tool’s intelligence is limited. Autoscan is included in the autoconf package.
Autoupdate
Not only can software packages be upgraded, but configure.ac can also be updated. Autoupdate automatically checks outdated macros in configure.ac and adjusts them to the new version. Autoupdate is included in the autoconf package.
Ifnames
A utility that lists all compiler preprocessing conditional commands (#if, #elif, #ifdef, #ifndef) in the source code, helping to verify whether autoscan-generated configure.ac has any missing parts. Ifnames is included in the autoconf package.
The following tools are not directly related to building but can be part of the GNU build system. They provide commands and some m4 macros to interface with autoconf.
libtool
Due to the differing library formats across operating systems (some even lack dynamic library support), their naming conventions and compiler parameters vary. Libtool introduced a new library format, libtool archive (.la suffix), and scripts to wrap compilation and linking commands.
Gettext
A tool for translating interface text. It replaces original strings in the source code with the gettext function (often defined as an underscore _("original string")). This allows exporting a .po file for translators, which is then compiled into a .mo file for the program to read interface text from.
Intltool
Part of the gettext system, intltool extends translation capabilities to non-source code stored messages (e.g., XML files, desktop files, UI definition files). It integrates these strings into .po files for translation, then reintegrates them back.
Gtk-doc
Generates API documentation from source code comments.
Note: Prefixes in autoconf macros
Macros used in autoconf come from various sources and are distinguished by different prefixes, akin to namespaces in other languages.
m4_: Original m4 macros and m4sugar (enhanced for usability). Original m4 macros are renamed with the m4_ prefix, except for file, line, dnl, and an autom4te-added macro oline.
AS_: m4sh macros. Shell commands are wrapped as macros for compatibility across different shells.
AC_: Autoconf macros.
AH_: Autoheader macros.
AT_: Autotest macros for writing test suites.
AU_: Deprecated macros, not recommended for use.
The above belong to the macros that come with autoconf.
AM_: Automake macros.
AX_: An autoconf extension package called autoconf-archive uses this namespace.
Resources:
Autoconf Tutorial: Only three articles were written, but they are worth reading from the basics.
GNU Software Page: Each GNU software page includes detailed documentation. It’s better to read these after having some understanding of the software to avoid confusion.
Usage: command --help (if it’s a shell built-in command, reverse the order: help command)
man: Manuals are essential.
Usage: man command (though you need the relevant manual pages installed)
texinfo: GNU system user manuals.
Usage: info [chapter] (mostly for advanced GNU users)
Author’s Note:
Some articles start with a flowchart, leading to "this generates that" without clearly explaining each part's purpose. To use it proficiently, you must first understand its function and principles. Simply imitating others won’t help you learn.
Additionally, many online flowcharts have flaws. Practice drawing your own.
中文 
Original link：https://bbs.deepin.org/zh/post/259750 Original author：enforcee
Building (compiling) is the process of creating standalone program products from source code. For some interpreted languages, the source code is usually the final product, so the build process is not involved. Thus, the term is usually applied to compiled languages like C, C++, etc. Specific build tools are designed for certain languages. During a single build process, multiple invocations of compilers, linkers, and other commands may be needed. Therefore, for a large project with many source files, manual control of this process is quite cumbersome, necessitating a set of "automatic build software" to help manage it. Although for developers using an IDE, building is just a matter of clicking a button, understanding the underlying principles is more beneficial for those seeking to excel.
There are many existing build software tools, each with different designs. Some build systems use an all-in-one step mode, completing the build with a single command; others require step-by-step operations: one command to check the system environment, modify compilation behavior, and generate build control files; another command to perform the actual compilation and linking based on the build control files. Common build combinations we use include configure+make, cmake+make, qmake+make, meson+ninja, etc. The combination of configure+make usually represents the GNU build system.
The GNU build system is divided into two parts: GNU make and GNU autotools. Make is a POSIX standard build tool with different implementations across various systems (the one we use in the GNU system is naturally GNU make). Hence, many build systems use make as the backend. GNU autotools include multiple components, with the main parts being GNU autoconf and GNU automake, aiming to create configure scripts. Since configure scripts are executed using the POSIX standard shell interpreter, once created, the operating system does not need to have GNU autotools installed to complete the build on any POSIX-compliant operating system.
Make
Make is a POSIX standard build tool, and its control file is the Makefile. A Makefile uses recipe-like syntax, where each recipe requires a "target," "prerequisites," and "commands" to form a complete part. Make can automatically detect changes in source files, so there’s no need to redo targets that haven’t changed in subsequent builds. The targets in the Makefile are also the commands for make; simply enter "make" to build the corresponding file. Some make targets can be set as "phony targets" (e.g., install, clean), which do not produce actual files but serve as commands or intermediate steps. These targets need to be specially marked to avoid confusion with actual files of the same name, ensuring make executes the corresponding commands.
Configure
Due to differences between operating system platforms, a Makefile may not always be compatible. Initially, the practice was to write a separate Makefile for each platform. In 1991, David J. MacKenzie handwrote a small shell script to detect platform characteristics and dynamically generate Makefiles for his program on 20 platforms, naming this script configure. Over time, it was adopted by other projects. MacKenzie later combined and packaged the frequently copied and pasted sections from various configure scripts into autoconf (see below). Nowadays, the configure scripts we see are usually generated by autoconf, though it’s rare for developers to write them manually anymore.
Configure is a shell script that checks whether the operating system environment meets compilation requirements and then generates Makefile and config.h files based on template files Makefile.in and config.h.in. Makefile is for make, while config.h contains build options for the C compiler’s preprocessing (included in C source code; once configure completes, make can use these options during compilation). Additionally, configure can accept runtime parameters to modify some compilation behaviors by generating different output files.
Autoconf
Autoconf generates configure scripts. It comprises various shell code snippets and uses the m4 macro processing language. A "macro" allows a (usually complex) original text to be represented by a shorthand (macro), which m4 then automatically expands into the original text.
Autoconf uses the configure.ac file as input. By adding autoconf-provided macros to this file and executing the autoconf command, configure.ac is expanded into the actual configure script. Autoconf actually uses an enhanced version of m4, autom4te, which includes caching functionality to prevent repeated execution of the same sections.
Autoheader
Autoheader automatically generates the config.h.in template file from configure.ac. Autoheader is included in the autoconf package.
Automake
Automake generates Makefile.in template files by writing Makefile.am, ensuring the final Makefile complies with GNU standards. Automake is similar to standalone make in expressing the transformation relationship between source and target files, but it is stricter, requiring the type of files to be specified. Additionally, since automake needs to interact with autoconf, it’s more restrictive compared to standalone make, which is not limited by programming language or platform.
Automake also reads configure.ac to obtain project information. Related functionalities of automake must be used in configure.ac, which requires another file, aclocal.m4, containing automake macros. The aclocal.m4 file is generated using the aclocal command, which is part of the automake package. If automake is used in a project, execute aclocal first; autoconf and automake can be executed as needed. (Refer to manuals for the execution order of other commands.)
Autoreconf
If the above sequence seems confusing, autoreconf can save the day. Autoreconf automatically executes all necessary commands to generate configure scripts, requiring only configure.ac and Makefile.am. It not only runs autoconf and automake but also supports many other commands. According to the manual, autoreconf runs autoconf, autoheader, aclocal, automake, libtoolize, intltoolize, gtkdocize, and autopoint when needed. Simply place the corresponding macros in configure.ac, and then run autoreconf.
Some software uses a script named bootstrap or autogen.sh to combine command sequences, doing similar work to autoreconf. With autoreconf available, there’s no need to create other scripts.
Although autoreconf automates command execution, it doesn't mean you can skimp on writing configuration files. Understanding autoconf and automake is still crucial. Autoreconf is included in the autoconf package.
Autoscan
Autoscan automatically checks source code and generates configure.ac (output file named configure.scan), which must be manually reviewed and modified before renaming to configure.ac for autoconf. The tool’s intelligence is limited. Autoscan is included in the autoconf package.
Autoupdate
Not only can software packages be upgraded, but configure.ac can also be updated. Autoupdate automatically checks outdated macros in configure.ac and adjusts them to the new version. Autoupdate is included in the autoconf package.
Ifnames
A utility that lists all compiler preprocessing conditional commands (#if, #elif, #ifdef, #ifndef) in the source code, helping to verify whether autoscan-generated configure.ac has any missing parts. Ifnames is included in the autoconf package.
The following tools are not directly related to building but can be part of the GNU build system. They provide commands and some m4 macros to interface with autoconf.
libtool
Due to the differing library formats across operating systems (some even lack dynamic library support), their naming conventions and compiler parameters vary. Libtool introduced a new library format, libtool archive (.la suffix), and scripts to wrap compilation and linking commands.
Gettext
A tool for translating interface text. It replaces original strings in the source code with the gettext function (often defined as an underscore _("original string")). This allows exporting a .po file for translators, which is then compiled into a .mo file for the program to read interface text from.
Intltool
Part of the gettext system, intltool extends translation capabilities to non-source code stored messages (e.g., XML files, desktop files, UI definition files). It integrates these strings into .po files for translation, then reintegrates them back.
Gtk-doc
Generates API documentation from source code comments.
Note: Prefixes in autoconf macros
Macros used in autoconf come from various sources and are distinguished by different prefixes, akin to namespaces in other languages.
The above belong to the macros that come with autoconf.
Resources:
http://www.idryman.org/blog/2016/03/10/autoconf-tutorial-1/
https://www.lrde.epita.fr/~adl/autotools.html
https://www.gnu.org/software/
Usage:
command --help(if it’s a shell built-in command, reverse the order:help command)Usage:
man command(though you need the relevant manual pages installed)Usage:
info [chapter](mostly for advanced GNU users)Author’s Note:
Some articles start with a flowchart, leading to "this generates that" without clearly explaining each part's purpose. To use it proficiently, you must first understand its function and principles. Simply imitating others won’t help you learn.
Additionally, many online flowcharts have flaws. Practice drawing your own.