Detailed description of Gnu AutoMake/Autoconf compilation configuration

Everyone who has used open-source C/C ++ projects knows that the standard compilation process has become a simple trilogy: configure/make install, which is very convenient to use, unlike writing code by yourself, you need to write a bunch of complicated makefiles by hand, and change the compiling environment. Makefile also needs to be modified (this is also true for Eclipse ).

Of course, this kind of good stuff will be used, but the GNU Autotool series is profound and profound, with a large number of tools and a large number of languages involved. If you can see it from the beginning, daylily will be cold, it is estimated that the project has ended long ago. There are a lot of examples of online search, but they are all examples of "hello world", which is far from achieving the goal of a large project.

Autotools procedure

In fact, Makefile, Makefile. in, and configure we see in large projects are basically not hand-written, and most of them are automatically generated by Autotool according to the environment. The Autotools tool consists of the following two parts:

** (1) Call each tool in sequence **
** (2) modify configure. ac, m4, and Makefile. am ***

The flowchart is as follows:

The procedure is as follows:

(1) the source code root directory calls the autoscan script to generate the configure. scan file, and rename the file to configure. ac (or configure. in, early use of the. in suffix)
(2) modify [configure. ac] and use various M4 macros provided by autoconf to configure various automatic test projects required by the project.
(3) compile a [custom macro]. It is recommended that each macro be a separate *. m4 file;
(4) call aclocal to collect various non-Autoconf macros used in configure. ac, including custom macros;
(5) Call autoheader to scan configure. ac (configure. in), acconfig. h (if any) to generate config. h. in macro definition file, which is mainly based on configure. the # define and # undefine macros generated by some specific macros (such as AC_DEFINE) in the ac are determined based on the actual test results (see the following example for details ).
(6) write one or more makefiles according to the rules specified by automake and the directory structure of the project. am] (Makefile. the am number and storage location are related to the source code directory structure), Makefile. am mainly writes the compilation target and its source code composition.
(7) call automake to convert each Makefile. am is converted to Makefile. in, and generate a series of files that meet the GNU coding specifications (the missing files are automatically added with the-a option, but several still need to be added by themselves, run touch news readme authors ChangeLog before running automake ). If configure. ac is configured to use libtool (which defines the AC_PROG_LIBTOOL macro (earlier version) or LT_INIT macro). Before this step, you must first execute libtoolize -- automake -- copy -- force in the project root directory, to generate ltmain. sh for automake and config. status call.
(8) call autoconf and use M4 to parse configure. ac to generate the shell script configure. After completing the preceding steps, the developer's work is completed, and subsequent customization is completed by the users of open-source software entering different parameters for configure as needed.
(9) the user calls configure, generates Makefile, and then make & make install.

Gnu Build System

Autoconf solves an important problem-finding accurate information about system construction and running, but this is only a small part of the problem in the process of developing portable software. For this purpose, the Gnu Project has developed an integrated tool set to complete this task: Gnu Build System. The most important tools in this tool are Autoconf, Automake, and Libtool. Let's take a look at what these tools actually do.

Automake

At first, the make tool existed, which means that makefile is almost the only software that provides automatic building rules. We specify the compilation rules by writing Makefile, but soon we encountered many restrictions, it lacks support for automatic dependency, recursive construction, and reliable timestamps (such as network file systems. This means that developers have to provide construction for every project. Project portability is very important, and it is mainly because make tools can run in many systems. All of this is done manually to implement dependencies between different target systems. Although we started to use Autoconf, we also need to add some repeated code in Makefile. in to identify @ CC @, @ CFLAG @, and use configure to do some replacement work. Automake emerged as a result of these chaotic and tedious steps.
Automake allows us to specify the build in the Makefile. am file. It is processed by some syntaxes that are simpler than Makefile, and then read Makefile. am through Autoconf to automatically generate Makefile. in. For example, Makefile. am is used to generate and install a "Hello World" program, which is roughly as follows:

Bin_PROGRAMS = hello
Hello_SOURCES = hello. c

The generated Makefile. in (approximately 400 rows) will automatically support all standard target platforms. Autoconf provides automatic replacement, automatic dependency resolution, and virtual path creation. Make to generate the hello program, and then install the program to/usr/local/bin through make install (or the path specified through configure prefix)

This directly enables Automake to be built, especially for large targets, but it also brings a lot of convenience and portability for small programs. Of course, the benefit is not only that.

Gnulib

Gnu software is very famous for running different types of systems, even if we only want to write software running on the Gnu system, however, many users and developers will also transplant our software to the system they are using.

Gnulib is the core of GNU code and can be contributed between free software packages. Its contribution is at the source code level, rather than as a library, and can be connected and used as needed. In this case, you need to copy Gnulib to your source code tree, and the tar package is not released. Developers can only get it from the repository, and the source code file can be obtained online, and follow the gnu gpl or gnu lgpl protocol.
The Gnu module mainly contains the C source code and configures the source code through a series of macros (Macro. For example, the stdbool module in Gnulib implements stdbool. h. The function in the header file is similar to the C99 standard, and even some hosts do not contain stdbool. h header file. This module contains the replaced header file. The Autoconf macro also organizes replacement of files on the old-fashioned system.

Libtool

Generally, we want to build not only programs, but also Libraries. Such programs can depend on these libraries to reduce labor. Ideally, we want these libraries to be contributed by multiple programs, and do not need to be copied between disks, and these libraries can be upgraded independently. However, this also brings about some problems. Each system has its own incompatible tool set, compilation identifier, module, and so on. Fortunately, Gnu provides a solution: LIbtool

Libtool solves the need for building shared libraries, and it seems that there is only one way. It solves many headaches, such as how to follow the Make rule for different variable prefixes in the shared library, and how to be linked and consistent version systems before being installed by the super administrator, although Libtool can be used independently without Automake, it can interact with Automake in the simplest way. In other words, libtool is usually automatically loaded when the shared library is required. We do not need to pay attention to its syntax.

In the following section, we will use the amhello example in the Autoconf manual to learn how to write these configuration files.

 

1. configure

The configuration script created by Autoconf is usually written.ConfigureWhen running, configure creates several files and replaces the parameters in the configuration with appropriate values. These files are:

 

The code is as follows:

Copy code

(1) one or more Makefile FILES, usually each source package and its subdirectories contain one. (2) an optional and configurable C header file, usually containing # define (3) One Config. statusTo identify the Configuration status. At runtime, the above files will be re-created (4) Config. cacheShell script Configure -- config-cacheIt stores multiple test results in configure (test is used in configure to detect various configuration environments ). (5) A config. log file contains the log information of multiple compilers to help debug configure with errors.

 

Use Autoconf to create ConfigureFile, we need to write an input file to assist in Autoconf operation Configure. ac(This should be common), and then run autoconf. If we need to write our own custom test features (custom macros) to supplement Autoconf, we should write a file Aclocal. m4And Acsite. m4. If we use the c header file to include these # define macro definitions, we also need to run AutoheaderThen, Config. hHeader file. In the following example, we will obviously feel that this header file is basically included in various source code files for our direct use of macros.

2. configure running process

 

The following figure shows how the configuration file is generated ,( * Indicates the running program. Optional files use closed []., AutoconfAnd AutoheaderRead Autoconf(By reading Autoconf. m4).

 

Autoconf1

 

If Automake is used, the following procedure will be performed:

 

Autoconf2

 

The following files are used in the software package configuration process (several files mentioned in the introduction)
Autoconf3

 

I am also dizzy here. There are too many files, but these are not all written by us. If every one is handwritten, it will not only waste time, but also be prone to errors, we can see that in the above process, many files can be generated through Autoconf, Automake, and configure to directly obtain the Makefile file we need. We need to write a general: configure. ac, makfile. am, and custom macro m4. In order,In the next section, we start with configure. ac.

Automatically generate configure. ac

1. Standard configure. ac structure

Before writing, let's first understand what configure. ac has.
The Autoconf macro sequence in configure is not very important. Some exceptions (Autoconf defines a large number of macro operations, such as definition, check, and output ). Each configure. ac must start with an AC_INIT macro and end with an AC_OUTPUT macro. In addition, some macros dependent on other macros must be called before they appear, because these macros need to check the values of some variables to determine what to do next. In addition, if the order is incorrect, there will be a warning during the configure process.

Of course, in order to maintain consistency in the writing process, there is a suggested Autoconf macro sequence. Generally, the macros behind the appearance can depend on the macros that appear earlier. For example, library functions are affected by some types and libraries.

The following is an example:

AC_INIT (package, version, bug-report-address)
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
AC_CONFIG_FILES ([file...])
AC_OUTPUT
2. Use autosacn to create configure. ac
The autoscan program helps us create or maintain the configure. ac file in a software package. Autoscan automatically scans and checks the directory tree (if specified) under the root directory of the source file or the current directory (not specified ). Autoscan searches for common portable files by meta files and creates the configure. scan file, which is the predecessor of configure. ac. Check whether the existing configure. ac is complete.

Of course, after using autoscan to create the configure. scan file, we recommend that you manually check the file before renaming it to configure. ac. Sometimes you need an adjustment. Autoscan occasionally outputs some macros with incorrect order, and then autoconf issues a warning. At this time, we need to manually adjust the order. If we want to use the configuration header file (usually config. h), we must add an AC_CONFIG_HEADER macro. We may also need to add or modify some # if condition definitions to help Autoconf complete the work.
When autoscan is used to generate configure. ac, we usually simply add some suggested conditions. In autoscan. log, each macro is included in what is required.

Autoscan uses multiple data files to determine which macros (macro) are output when it discovers special identifiers in the source code package. The formats of these data files are consistent: each line contains one identifier and one

Or multiple spaces. If an identifier is displayed, the corresponding macro is output. The first line # indicates the comment.

3. Use ifnames to output conditions
Ifnames can help us compile configure for some source code packages. ac, which can print out the existing C pre-processor conditions in this package, it can help fill in some configure generated by autoscan. ac is insufficient. Ifnames scans all c source files and outputs them in the form of # if, # elif, # ifdef, # ifndef in sequence.

4. Use autoconf to create configure

Execute the autoconf program (without parameters). autoconf uses the m4 macro processor and Autoconf macro to process configure. if a parameter is added for execution, autoconf reads the file specified by the parameter instead of configure. ac. If the parameter is-, it will read from the standard input and output to the standard output.

Autoconf macro is defined in multiple files. Some files generated by Autoconf are preferentially read by autoconf, and then autoconf checks the acsite. m4 file to view other files containing Autoconf.

5. Use autoreconf to update the configure script file

It is annoying to install different components for GNU Build System. For example, run autopoint to install Gettext and generate Makefile under automake in various directories. in and so on, but sometimes these are all necessary, if some changes, such as-update configure. ac again.

Autoreconf can be considered as a combination of autoconf, autoheader, acloacl, automake, libtoolize, and autopoint, and will be executed in proper order.

Compile to see how to implement automated compilation configuration.

Gnu Build System use case Hello World!

Preface
Front ??? Gong filter stolen sodium ?? What is the interface between food poverty and the wall? Are you sure you want to crash? Wei? Nu Build System involves too many things, and more knowledge can only be read by the development documentation. Now let's look at a specific example. Is there any expectation?

This example comes from the example program that comes with automake installation, in/usr/share/doc/automake/amhello-1.0.tar.gz, you can look for using linux System kids shoes. We can also create it on our own.

Prepare files

The hello world example is very simple. You only need to write five files:

First, create the source code directory cd & makdir amhello as the source code root directory.
Go to cd amhello and create the source code directory mkdir src.
The directory structure is ~ /Amhello/src: create the first file main. c in the src Directory. The source code is as follows:

# Include <config. h>
# Include <stdio. h>
Int
Main (void)
{
Puts ("Hello World! ");
Puts ("This is" PACKAGE_STRING ".");
Return 0;
}

Create the project description file README in the amhello Directory. The content is random ....

Makefile. am and src/Makefile. am contains the description of Automake in these two directories, so create Makefile in the amhello directory. am, create Makefile under src. am. the content is as follows:

Amhello/src/Makefile. am

Bin_PROGRAMS = hello
Hello_SOURCES = main. c
Amhello/Makefile. am

SUBDIRS = src
Dist_doc_DATA = README

Create configure. ac to help Autoconf generate the configure script. The content is as follows:

 

AC_INIT ([amhello], [1.0], [bug-automake@gnu.org])
AM_INIT_AUTOMAKE ([-Wall-Werror foreign])
AC_PROG_CC
AC_CONFIG_HEADERS ([config. h])
AC_CONFIG_FILES ([
Makefile
Src/Makefile
])
AC_OUTPUT

Execute the compilation and installation process

After the preceding five files are ready, execute autoreconf -- install in the amhello Directory (the role of autoreconf is described in the previous article, which is equivalent to the role of aclocal, autoconf, and other programs ). The following result is displayed:

~ /Amhello % autoreconf -- install
Configure. ac: installing './install-SH'
Configure. ac: installing './missing'
Configure. ac: installing './compile'
Src/Makefile. am: installing './depcomp

This indicates that the build is complete.

In addition to the three script files in the output, we can see that autoreconf has created four other files: configure, config. h, Makefile. in and src/Maiefile. in, we will find Makefile. makefile is generated in the am directory. in. The last three files are the templates used by the configure script to generate the system config. h, Makefile, and src/Makefile.

 

Checking for a BSD-compatible install.../usr/bin/install-c
Checking whether build environment is sane... yes
Checking for gawk... no
Checking for mawk... mawk
Checking whether make sets $ (MAKE)... yes
Checking for gcc... gcc
Checking for C compiler default output file name... a. out
Checking whether the C compiler works... yes
Checking whether we are cross compiling... no
Checking for suffix of executables...
Checking for suffix of object files... o
Checking whether we are using the gnu c compiler... yes
Checking whether gcc accepts-g... yes
Checking for gcc option to accept ISO c89... none needed
Checking for style of include used by make... GNU
Checking dependency style of gcc... gcc3
Configure: creating./config. status
Config. status: creating Makefile
Config. status: creating src/Makefile
Config. status: creating config. h
Config. status: executing depfiles commands
Then we can see that Makefile, src/Makefile, and config. h are generated. Now we can run the target we expect to generate.

Execute make in the amhello directory, and then generate src/hello in the src directory according to the configuration target, and execute src/hello

Hello World!
This is amhello 1.0.

However, please note that we only need to execute autoreconf if the Gnu Build System does not exist. As mentioned in the previous article, autoreconf is a group that calls autoconf, automake and other scripts for a series of commands. What we need to understand now is how these files are generated. Autoconf is used to generate configure through configure. ac, while automake is used to generate Makefile. ins through Makefile. ams and configure. ac. We should at least know how to manually create it in the correct order. Let's show you a picture to help you understand.

Description of configure. ac configuration in amhello's

Let's review configure. ac:

AC_INIT ([amhello], [1.0], [bug-automake@gnu.org])
AM_INIT_AUTOMAKE ([-Wall-Werror foreign])
AC_PROG_CC
AC_CONFIG_HEADERS ([config. h])
AC_CONFIG_FILES ([
Makefile
Src/Makefile
])
AC_OUTPUT

This file must be used by autoconf (create configure) and automake (create different Makefile. am s ). It contains M4 macros of some columns, which will be extended into shell code and finally organized into the configure script. The specific syntax of this file is available in the Autoconf manual.
We can see that the macros in this file are prefixed with AC _, and these are Autoconf macros. You can query the Autoconf manual for the role of each macro.

AC_INIT

First two rows

AC_INIT ([amhello], [1.0], [bug-automake@gnu.org])
AM_INIT_AUTOMAKE ([-Wall-Werror foreign])

As the initialization of Autoconf and Automake. The parameters required for AC_INIT are AC_INIT ([package name], [version number], and [bug report email]). We can execute this email address. /configure -- help command. The version number and package name will be used during packaging. You can run make dist to package the main files in the source code into the package name -example .tar.gz.

AC_INIT_AUTOMAKE

The AM_INIT_AUTOMAKW parameter is a set of options about automake execution. -Wall and-Werror allow automake to enable all warnings and report errors. The warnings mentioned here, for example, suspicious commands in Makefile. am, have nothing to do with how to call the compiler, even if they can be supported by similar naming options. For our new users, using-Wall-Werror is a very safe setting for packet building, and we do not want to miss any problems. After being proficient, we can relax and know what can be left behind. The foreign option notifies the Automake program that the build of this package does not follow the Gnu standard. These files must be included in the Gnu standard, such as Changelog and AUTHORS. Similar to github projects we normally use, a README. md file is generally required to describe the project. We do not want automake to report missing files.

AC_PROG_CC

The final role of AC_PORG_CC is to allow the configure script to search for the c compiler in the system, define the C compiler as the variable CC, and then src/Makefile. the in file can use Automake to generate the execution program hello using CCa, so when configure uses src/Makefile. when the src/Makefile file is created in, it defines the C compiler found as CC. If Automake is required to create Makefile through CC. in, while configure. if CC is not defined in ac, it will prompt us to add AC_PROC_CC.

AC_CONFIG_HEADER

AC_CONGIF_HEADER ([config. h]). This macro is mainly used to create config. h, it will set configure. the Macros defined by other macros in ac are concentrated in config in the form of # define. h. In our example, the AC_INIT macro has defined some macros. Here is the content of config. h after execution of./configure:

/* Config. h. Generated from config. h. in by configure .*/
/* Config. h. in. Generated from configure. ac by autoheader .*/

/* Name of package */
# Define PACKAGE "amhello"

/* Define to the address where bug reports for this package shoshould be sent .*/
# Define PACKAGE_BUGREPORT "bug-automake@gnu.org"

/* Define to the full name of this package .*/
# Define PACKAGE_NAME "amhello"

/* Define to the full name and version of this package .*/
# Define PACKAGE_STRING "amhello 1"

/* Define to the one symbol short name of this package .*/
# Define PACKAGE_TARNAME "amhello"

/* Define to the home page for this package .*/
# Define PACKAGE_URL ""

/* Define to the version of this package .*/
# Define PACKAGE_VERSION "1"

/* Version number of package */
# Define VERSION "1"
We will find that the header file in src/main. c contains config. h, so main. c can directly use PACKAGE_STRING. In actual projects, config. h will be very large, and almost every feature of the system will have a # define definition.

AC_CONFIG_FILES

The AC_CONFIG_FILES macro declares a set of Makefile FILES to be generated by configure through Makefile. ins. Automake also needs to scan this list to find the Makefile. am to be processed. (Special emphasis: Once we add a new directory to the project, we should add the Makefile under this directory to this list. Otherwise, even if we thank Makefile in this directory. am, Automake will not process ).

AC_OUTPUT

AC_OUTPUT is an end command, which is actually the end of the AC_CONFIG_HEADERS and AC_CONFIG_FILES commands and outputs the files generated after the two processes.
For a new project, we 'd better start with such a simple configure. ac file and then gradually increase the test requirements. The autoscan command can also help us add some testing requirements. Manually execute autoscan and then modify it. Note the order of different test macros in the file.

Makefile. am configuration in amhello
Now let's take a look at src/Makefile. am.

Bin_PROGRAMS = hello
Hello_SOURCES = main. c

The Makefile. am syntax is the same as the Makefile syntax. Automake processes Makefile. when am is used, it will put Makefile. am is completely copied to Makefile. in (Makefile. the in file will be processed as Makefile by configure later), but some variable definitions will be changed according to some build rules and variables. Generally, Makefile. ams only contains a set of variable definitions in the preceding example, but they can also contain some variables and rule definitions, which will be passed through automake without explanation.

Bin_PROGRAMS

Variables suffixed with _ PROGRAMS belong to special variables in the variable list. They are generated by Makefile. The final section execution file in our example is hello. From the Automake perspective, bin_PROGRAMS is divided into two parts. The variable ending with the _ PROGRAMS suffix is the main variable. Automake recognizes other major variables such as _ SCRIPTS, _ DATA, and _ LIBRARIES, corresponding to different files.
The bin section in bin_PROGRAMS is used to tell automake that the program generated by final compilation should be installed in bindir.
A series of variables are used in GNU Build System to provide the location of the target directory and allow users to customize the location of these paths. Any such variable can be used to specify the locations where different files are put.
For example:

Bindir is used to install the directory of executable files run by users.
Datadir is used to install read-only directories of data unrelated to the structure.
Includedir is used to install the Directory of the C header file.

See the definition of these variables in the GNU coding standard.
In addition, Automake also knows that different types of files need to be opened in a distributed manner when creating the packaging file. The side effect of hello_SOURCES is that executing make dist is a part of main. c as a tarball.

Now let's look at Makefile. am in the project directory.

SUBDIRS = src
Dist_doc_DATA = README
SUBDIRS

SUBDIR is a special variable that lists the directories that make recursively processes before processing the current directory. In this example, use make to process src/And then the files under amhello. Install src/README before installing src/hello.

Dist_doc_DATA

Dist_doc_DATA = README, because README will be installed in docdir, because the files after _ DATA will not be created during dist packaging, therefore, we add a dist prefix before _ DATA. This README is not required. The important influence is to install README during make install.