GNU Automake 1.16.3：类Unix环境下的标准Makefile生成器

需积分: 5 181 浏览量更新于2024-07-09 收藏 864KB PDF 举报

GNU Automake是一款专为类Unix环境设计的编译构建工具，版本为1.16.3，发布日期为2020年11月19日。它由David MacKenzie、Tom Tromey、Alexandre Duret-Lutz、Ralf Wildenhues和Stefano Lattarini等人共同开发，其主要功能是根据模板文件自动生成符合GNU标准的Makefile。该工具的核心在于创建一个统一的、可扩展的构建系统，旨在简化软件项目的自动化配置和编译流程。 1. **简介**: Automake作为GNU Build System的一部分，提供了高度标准化的Makefile生成机制，使得开发者能够遵循一套统一的构建规范，确保跨平台的一致性和易于维护性。它特别适用于那些需要在类Unix系统（如Linux、BSD等）上部署和构建的项目。 2. **GNU构建系统的介绍**: - **基础概念**: Automake与configure脚本一起工作，构建系统基于一组自动化工具，包括Autoconf和Automake，它们共同创建和维护项目的结构，并确保在不同的平台上编译程序的正确性。 - **使用场景**: - **基本安装**：Automake支持简化项目的安装过程，通过模板定义编译选项和依赖关系，使得新用户的初次配置变得简单。 - **标准Makefile目标**：提供了一系列预定义的Makefile目标，如`configure`, `make`, `install`, `clean`, 和 `distclean`，使得开发者可以专注于代码本身，而不是底层的构建逻辑。 - **目录变量**：Automake定义了一些标准的目录变量，如`srcdir`, `bindir`, `libdir`, 等，用于组织源代码、可执行文件和库的位置，方便管理项目结构。 - **配置变量**：配置变量如`AC_SUBST`和`AM_CONDITIONAL`允许动态地设置Makefile中的内容，根据特定条件调整编译选项。 - `config.site`：这是一种配置文件，可以用来覆盖或修改默认的配置设置，为特定平台或用户需求提供个性化选项。 3. **并行构建树（VPATH Build）**: Automake支持VPATH（Value-From-Prefix-Path），这是一种构建技术，允许Make在多个源文件夹（build trees）之间查找源代码，从而简化了大型项目中的多模块协作。通过设置`VPATH`变量，Make可以在指定的路径列表中搜索源文件，而无需显式指定每个文件的确切位置。 GNU Automake是一款强大的工具，它通过规范化Makefile的编写方式，极大地提升了类Unix环境中软件项目的构建效率和移植性。熟练掌握Automake和其相关工具，对于开发跨平台软件至关重要。

Chapter 2: An Introduction to the Autotools 9

2.2.8 Cross-Compilation

To cross-compile is to build on one platform a binary that will run on another platform.

When speaking of cross-compilation, it is important to distinguish between the build plat-

form on which the compilation is performed, and the host platform on which the resulting

executable is expected to run. The following configure options are used to specify each of

them:

--build=build

The system on which the package is built.

--host=host

The system where built programs and libraries will run.

When the --host is used, configure will search for the cross-compiling suite for

this platform. Cross-compilation tools commonly have their target architecture as preﬁx

of their name. For instance my cross-compiler for MinGW32 has its binaries called

i586-mingw32msvc-gcc, i586-mingw32msvc-ld, i586-mingw32msvc-as, etc.

Here is how we could build amhello-1.0 for i586-mingw32msvc on a GNU/Linux PC.

~/amhello-1.0 % ./configure --build i686-pc-linux-gnu --host i586-mingw32msvc

checking for a BSD-compatible install... /usr/bin/install -c

checking whether build environment is sane... yes

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking for i586-mingw32msvc-strip... i586-mingw32msvc-strip

checking for i586-mingw32msvc-gcc... i586-mingw32msvc-gcc

checking for C compiler default output file name... a.exe

checking whether the C compiler works... yes

checking whether we are cross compiling... yes

checking for suffix of executables... .exe

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether i586-mingw32msvc-gcc accepts -g... yes

checking for i586-mingw32msvc-gcc option to accept ANSI C...

...

~/amhello-1.0 % make

...

~/amhello-1.0 % cd src; file hello.exe

hello.exe: MS Windows PE 32-bit Intel 80386 console executable not relocatable

The --host and --build options are usually all we need for cross-compiling. The only

exception is if the package being built is itself a cross-compiler: we need a third option to

specify its target architecture.

--target=target

When building compiler tools: the system for which the tools will create output.

For instance when installing GCC, the GNU Compiler Collection, we can use --target=

target to specify that we want to build GCC as a cross-compiler for target. Mixing

--build and --target, we can actually cross-compile a cross-compiler; such a three-way

cross-compilation is known as a Canadian cross.

See Section “Specifying the System Type” in The Autoconf Manual, for more information

about these configure options.

Chapter 2: An Introduction to the Autotools 10

2.2.9 Renaming Programs at Install Time

The GNU Build System provides means to automatically rename executables and man-

pages before they are installed (see Section 11.2 [Man Pages], page 95). This is especially

convenient when installing a GNU package on a system that already has a proprietary im-

plementation you do not want to overwrite. For instance, you may want to install GNU

tar as gtar so you can distinguish it from your vendor’s tar.

This can be done using one of these three configure options.

--program-prefix=prefix

Prepend preﬁx to installed program names.

--program-suffix=suffix

Append suﬃx to installed program names.

--program-transform-name=program

Run sed program on installed program names.

The following commands would install hello as /usr/local/bin/test-hello, for in-

stance.

~/amhello-1.0 % ./configure --program-prefix test-

...

~/amhello-1.0 % make

...

~/amhello-1.0 % sudo make install

...

2.2.10 Building Binary Packages Using DESTDIR

The GNU Build System’s make install and make uninstall interface does not exactly ﬁt

the needs of a system administrator who has to deploy and upgrade packages on lots of

hosts. In other words, the GNU Build System does not replace a package manager.

Such package managers usually need to know which ﬁles have been installed by a package,

so a mere make install is inappropriate.

The DESTDIR variable can be used to perform a staged installation. The package should

be conﬁgured as if it was going to be installed in its ﬁnal location (e.g., --prefix /usr), but

when running make install, the DESTDIR should be set to the absolute name of a directory

into which the installation will be diverted. From this directory it is easy to review which

ﬁles are being installed where, and ﬁnally copy them to their ﬁnal location by some means.

For instance here is how we could create a binary package containing a snapshot of all

the ﬁles to be installed.

~/amhello-1.0 % ./configure --prefix /usr

...

~/amhello-1.0 % make

...

~/amhello-1.0 % make DESTDIR=$HOME/inst install

...

~/amhello-1.0 % cd ~/inst

~/inst % find . -type f -print > ../files.lst

Chapter 2: An Introduction to the Autotools 11

~/inst % tar zcvf ~/amhello-1.0-i686.tar.gz ‘cat ../files.lst‘

./usr/bin/hello

./usr/share/doc/amhello/README

After this example, amhello-1.0-i686.tar.gz is ready to be uncompressed in / on

many hosts. (Using ‘cat ../files.lst‘ instead of ‘.’ as argument for tar avoids entries

for each subdirectory in the archive: we would not like tar to restore the modiﬁcation time

of /, /usr/, etc.)

Note that when building packages for several architectures, it might be convenient to use

make install-data and make install-exec (see Section 2.2.7 [Two-Part Install], page 8)

to gather architecture-independent ﬁles in a single package.

See Chapter 12 [Install], page 96, for more information.

2.2.11 Preparing Distributions

We have already mentioned make dist. This target collects all your source ﬁles and the

necessary parts of the build system to create a tarball named package-version.tar.gz.

Another, more useful command is make distcheck. The distcheck target constructs

package-version.tar.gz just as well as dist, but it additionally ensures most of the use

cases presented so far work:

• It attempts a full compilation of the package (see Section 2.2.1 [Basic Installation],

page 2): unpacking the newly constructed tarball, running make, make dvi, make check,

make install, as well as make installcheck, and even make dist,

• it tests VPATH builds with read-only source tree (see Section 2.2.6 [VPATH Builds],

page 6),

• it makes sure make clean, make distclean, and make uninstall do not omit any ﬁle

(see Section 2.2.2 [Standard Targets], page 4),

• and it checks that DESTDIR installations work (see Section 2.2.10 [DESTDIR], page 10).

All of these actions are performed in a temporary directory, so that no root privileges

are required. The exact location and the exact structure of such a subdirectory (where the

extracted sources are placed, how the temporary build and install directories are named

and how deeply they are nested, etc.) is to be considered an implementation detail, which

can change at any time; so do not rely on it.

Releasing a package that fails make distcheck means that one of the scenarios we pre-

sented will not work and some users will be disappointed. Therefore it is a good practice

to release a package only after a successful make distcheck. This of course does not imply

that the package will be ﬂawless, but at least it will prevent some of the embarrassing errors

you may ﬁnd in packages released by people who have never heard about distcheck (like

DESTDIR not working because of a typo, or a distributed ﬁle being erased by make clean,

or even VPATH builds not working).

See Section 2.4.1 [Creating amhello], page 13, to recreate amhello-1.0.tar.gz using

make distcheck. See Section 14.4 [Checking the Distribution], page 100, for more informa-

tion about distcheck.

2.2.12 Automatic Dependency Tracking

Dependency tracking is performed as a side-eﬀect of compilation. Each time the build

system compiles a source ﬁle, it computes its list of dependencies (in C these are the header

Chapter 2: An Introduction to the Autotools 12

ﬁles included by the source being compiled). Later, any time make is run and a dependency

appears to have changed, the dependent ﬁles will be rebuilt.

Automake generates code for automatic dependency tracking by default, unless the devel-

oper chooses to override it; for more information, see Section 8.19 [Dependencies], page 82.

When configure is executed, you can see it probing each compiler for the dependency

mechanism it supports (several mechanisms can be used):

~/amhello-1.0 % ./configure --prefix /usr

...

checking dependency style of gcc... gcc3

...

Because dependencies are only computed as a side-eﬀect of the compilation, no depen-

dency information exists the ﬁrst time a package is built. This is OK because all the ﬁles

need to be built anyway: make does not have to decide which ﬁles need to be rebuilt. In

fact, dependency tracking is completely useless for one-time builds and there is a configure

option to disable this:

--disable-dependency-tracking

Speed up one-time builds.

Some compilers do not oﬀer any practical way to derive the list of dependencies as a side-

eﬀect of the compilation, requiring a separate run (maybe of another tool) to compute these

dependencies. The performance penalty implied by these methods is important enough to

disable them by default. The option --enable-dependency-tracking must be passed to

configure to activate them.

--enable-dependency-tracking

Do not reject slow dependency extractors.

See Section “Dependency Tracking Evolution” in Brief History of Automake, for some

discussion about the diﬀerent dependency tracking schemes used by Automake over the

years.

2.2.13 Nested Packages

Although nesting packages isn’t something we would recommend to someone who is dis-

covering the Autotools, it is a nice feature worthy of mention in this small advertising

tour.

Autoconﬁscated packages (that means packages whose build system have been created

by Autoconf and friends) can be nested to arbitrary depth.

A typical setup is that package A will distribute one of the libraries it needs in a sub-

directory. This library B is a complete package with its own GNU Build System. The

configure script of A will run the configure script of B as part of its execution; build-

ing and installing A will also build and install B. Generating a distribution for A will also

include B.

It is possible to gather several packages like this. GCC is a heavy user of this feature.

This gives installers a single package to conﬁgure, build and install, while it allows developers

to work on subpackages independently.

Chapter 2: An Introduction to the Autotools 13

When conﬁguring nested packages, the configure options given to the top-level

configure are passed recursively to nested configures. A package that does not

understand an option will ignore it, assuming it is meaningful to some other package.

The command configure --help=recursive can be used to display the options sup-

ported by all the included packages.

See Section 7.4 [Subpackages], page 53, for an example setup.

2.3 How Autotools Help

There are several reasons why you may not want to implement the GNU Build System

yourself (read: write a configure script and Makefiles yourself).

• As we have seen, the GNU Build System has a lot of features (see Section 2.2 [Use

Cases], page 2). Some users may expect features you have not implemented because

you did not need them.

• Implementing these features portably is diﬃcult and exhausting. Think of writing

portable shell scripts, and portable Makefiles, for systems you may not have handy.

See Section “Portable Shell Programming” in The Autoconf Manual, to convince your-

self.

• You will have to upgrade your setup to follow changes to the GNU Coding Standards.

The GNU Autotools take all this burden oﬀ your back and provide:

• Tools to create a portable, complete, and self-contained GNU Build System, from simple

instructions. Self-contained meaning the resulting build system does not require the

GNU Autotools.

• A central place where ﬁxes and improvements are made: a bug-ﬁx for a portability

issue will beneﬁt every package.

Yet there also exist reasons why you may want NOT to use the Autotools. . . For instance

you may be already using (or used to) another incompatible build system. Autotools will

only be useful if you do accept the concepts of the GNU Build System. People who have

their own idea of how a build system should work will feel frustrated by the Autotools.

2.4 A Small Hello World

In this section we recreate the amhello-1.0 package from scratch. The ﬁrst subsection

shows how to call the Autotools to instantiate the GNU Build System, while the second

explains the meaning of the configure.ac and Makefile.am ﬁles read by the Autotools.

2.4.1 Creating amhello-1.0.tar.gz

Here is how we can recreate amhello-1.0.tar.gz from scratch. The package is simple

enough so that we will only need to write 5 ﬁles. (You may copy them from the ﬁnal

amhello-1.0.tar.gz that is distributed with Automake if you do not want to write them.)

Create the following ﬁles in an empty directory.

• src/main.c is the source ﬁle for the hello program. We store it in the src/ subdi-

rectory, because later, when the package evolves, it will ease the addition of a man/

directory for man pages, a data/ directory for data ﬁles, etc.

~/amhello % cat src/main.c

剩余185页未读，继续阅读

crownyanguan

粉丝: 9
资源: 8

GNU Automake 1.16.3：类Unix环境下的标准Makefile生成器

autoconf和automake.pdf

autoconf.pdf automake.pdf makefile中文版

轻松学automake.pdf

compiler.automake.allow.when.app.running找不到

idea gradle 热部署

idea javaweb项目热部署

automake升级

idea中springboot的热部署

springboot热部署时间怎么修改

最新资源