"Autotools-gnu Autoconf, Automake and Libtool Practitioners ' Guide" chapter I

Preface

This article is based on the translation of the first chapter of Autotools-a Practioner's Guide to GNU Autoconf, Automake, and Libtool, omitting some of the statements.

Body

As the preface says, the GNU Autotools is designed to make life easier for end users, not defenders. Even so, in the long run, using Autotools as a project manager will make your job easier, though it may not be the reason you suspect it. The Autotools framework is as simple as possible, giving the functionality it provides. The real purpose of Autotools is twofold: it serves your users and makes your project incredibly portable---even on systems you've never tested, installed, or built your code.

In this book, I will often use the words autotools, although you can not find the use of this word in the GNU Archive package. I use this word to denote the following three GNU packages, which are considered by the community to be part of the GNU compilation system

　> Autoconf: Used to generate configuration scripts for the project;

>　 automake: Used to simplify the process of creating consistency and functional makefile;

　> libtools: Used to provide an abstraction for portable creation of shared libraries;

Other build tools, such as the CMake and SCons, try to provide the same functionality as Autotools but in a more user-friendly way. However, these tools are trying to hide behind the graphical user interface and the script builder's functionality, which in effect ultimately makes them weaker.

who should use Autotools

If you are writing a target machine that is open source software for UNIX or Linux, you should definitely be using the GNU Autotools. Even if you are writing proprietary software for UNIX or Linux, you will benefit greatly from them. Autotools will provide you with a build environment that allows your project to be built successfully in your future version or branch, using almost unchanged build scripts. This is useful even if you're just going to target a single Linux distribution because, honestly, you really don't know in advance whether your company will want your software to run on other platforms in the future.

Choice of Language

The choice of your programming language is another important factor in deciding whether to use Autotools. Remember that Autotools was designed by GNU to manage the GNU project. In the GNU community, there are two factors that determine the importance of a computer programming language:

　> There is no GNU pack written in this language

　> Does the GNU compilation Toolset support this language?

Based on these two criteria,Autotools provides native support for the following languages (supported by native, I mean autotools will compile, link, and run the source-level feature check in these languages):

　> C

　> C + +

　> Objective C

　> Fortran

　> Fortran 77

　> Erlang

So if you want to build a Java package, you can configure Automake to do so (as we see in chapters 8th and 9th), but you can't ask autoconf to compile, link, or run a Java-based check because Autoconf doesn't natively support Java. However, you can find the AUTOCONF macro (which I'll cover in more detail in the next section) to improve the ability of autoconf to manage the configuration process of the project written in Java.

Open source software developers are actively working on GCJ compilers and toolsets, so some native Java support may eventually be added to the autoconf. But by the time the book was written, GCJ was still immature, and few GNU packets were currently written in Java, so the problem was still not critical for the GNU community.

Build your package compilation system

The GNU Autotools framework consists of three main packages: Autoconf,automake, and Libtool. The tools in these packages can produce code that relies on utility software and features from Gettext,m4,sed,make, and other packages such as Perl.

For Autotools, it is important to differentiate between the maintainer's system and the end user's system. Autotools is designed to indicate that a Autotools-generated compilation system should be tightly dependent on ready-made tools that are pre-installed on end-user machines . For example, a machine used by a maintainer to create a branch requires a Perl interpreter, but an end-user-run machine does not need Perl to build the product from the release branch package.

One corollary is that end-user machines do not need to install Autotools, and an end-user system requires only a reasonable version of the POSIX-compliant make and Bourne shell variants to execute the resulting configuration script. Of course, any package will also require the compiler, linker, and other tools that the project maintainer deems necessary to translate the original code files into executable binaries, help files, and other runtime resources.

If you have ever downloaded, built and installed software from Tarball (a compressed archive of. tar.gz,. tgz,. tar.bz2 or other extensions), you undoubtedly know the whole process. It usually looks like this:

$ GZIP-CD hackers-delight-1.0.tar.gz | Tar xvf-...
$ CD hackers-delight-1.0
$./configure && make
...
$ sudo make install
...

Autoconf

Although the configuration script is long and complex, users only need to specify some variables at execution time. Most variables are simple choices about components, attributes, and options, such as: where the compilation system can find libraries and header files. The final product where I want to install. I want to build some of the optional components into my product.

The configuration script generated by autoconf provides a common set of options that are important for all portable software projects running on POSIX systems. This includes options for modifying the standard location (a concept that I will cover in the 2nd chapter), as well as the project-specific options defined in the Configure.ac file (which I'll discuss in chapter 3rd).

The AUTOCONF package provides several programs, including the following:

　> autoconf

　> Autoheader

　> autom4te

　> autoreconf

　> AutoScan

　> AutoUpdate

　> ifnames

autoconf

Autoconf is a simple Bourne shell script. Its main function is to ensure that the current shell contains the necessary functionality to execute the M4 macro processor (I will discuss the M4 use of autoconf in chapter 3rd). The remainder of the script resolves the command-line arguments and executes the autom4te.

autoreconf

The Autoreconf tool executes the configuration tools in the Autoconf,automake and Libtool packages required by each project. autoreconf minimizes the amount of respawn that reports timestamp, feature, and project status changes . It is written as an attempt to consolidate the script-based tools written by existing maintainers to run all required autotools in the correct order. You can think of autoreconf as an intelligent autotools boot tool. If all you have is a configure.ac file, you can run autoreconf to execute all the tools you need in the correct order so that configure will be properly generated.

Autoheader

The Autoheader tool produces a C + + compatible header file template , based on a variety of structures within the configure.ac. This file is often referred to as config.h.in. When the end user executes configure, the configuration script generates config.h based on config.h.in. As a maintainer, you will use Autoheader to generate template files that will be included in your branch package. (We will examine autoheader in detail in the 3rd chapter).

AutoScan

The AutoScan program generates a default Configure.ac file for the new project ; it can also check for defects and opportunities in an existing Autotools project for enhancement. (We will be autoscan in chapters 3rd and 8th). AutoScan is useful for a starting point for a project that uses a compiled system that is not based on Autotools, but it may also be useful in prompting for enhancements to an existing Autotools engineering-based feature.

AutoUpdate

The AutoUpdate tool is used to upgrade the Configure.ac or template (. in) file to match the syntax supported by the current Autotools version.

Ifnames

The Ifnames program is a gadget that is not normally fully used, and it can accept the list of source file names on the command line and display the C preprocessor definition lists on the STDOUT device. This tool is designed to help maintainers decide to put content in Configure.ac and makefile.am files so that they can be ported . If your engineering considerations are written in a way that is portable, ifnames can help you decide which parts of your source tree you are trying to migrate, and give you the names of potentially portable definitions.

Autom4te

The Autom4te tool is a smart cache wrapper for M4 , which is used by most of the other Autotools tools. The Autom4te cache reduces the time that successive tools access configure.ac by up to 30%. I don't want to spend too much time on autom4te (pronounced automate) because it is mainly used by internal autotools. The only sign that it works is that the Autom4te.cache directory will appear in your project's top-level directory after you run Autoconf or autoreconf.

Working together

In the work listed earlier,autoconf and Autoheader are the only ones that the project maintainer will use directly when generating configure Scripts ,autoreconf is The only thing developers need to do directly . Figure 1-1 shows the input file and autoconf interacting with the autoheader, resulting in the corresponding product file.

　　Note: in this book I will use the streaming diagram in Figure 1-1. The black box represents the Autotools software package, and the white box represents the generated object. A square corner box is a script; a fillet box is a data file. The meaning of most tags here should be obvious, at least one need to explain: The term ac-vars refers to autoconf specific replacement text. Soon I'll explain the aclocal.m4 box with the gradient of the boxes.

The main task of this set of tools is to generate a configuration script that can be used to configure a project build directory. This script does not depend on autotools themselves; in fact, autoconf is designed to generate configuration scripts that can run on all UNIX-like platforms and most Bourne shell variants. This means that you can use autoconf to generate a configuration script that can then be executed on a machine that does not have Autotools installed.

Autoconf and Autoheader programs are either executed directly by the user or executed indirectly by autoreconf. They get input from Configure.ac files in your project and multiple M4 macro definition files that conform to autoconf, and use Autom4te to maintain cache information. Autoconf generates a configuration script called configure, a very easy-to-migrate Bourne shell script that gives your project a lot of useful configuration capabilities. Autoheader generates a config.h.in template based on a specific macro definition in Configure.ac.

Automake