GNU Make：项目管理专家罗伯特·梅克伦堡的实用指南

4星 · 超过85%的资源需积分: 19 11 浏览量更新于2024-07-25 4 收藏 3.26MB PDF 举报

GNU Make 是一个强大的自动化构建工具，广泛应用于软件开发中的项目管理和编译过程。本文档的作者 Robert Mecklenburg 是一位经验丰富的 IT 专家，自 1977 年起就开始使用 Unix 并在专业编程领域工作了 23 年。他的 make 使用历史可以追溯到 1982 年 NASA 的 Unix Version 7 时期。作为计算机科学博士，他在机械 CAD、生物信息学等多个领域积累了深厚的经验，并将这些技能应用于项目管理中，尤其与 C++、Java 和 Lisp 等编程语言的结合。书中详细讲解了如何利用 GNU Make 进行高效、有序的项目构建，包括规则定义、目标依赖关系管理、条件编译和自动化任务执行等核心概念。Makefile（Make 的配置文件）是项目的基石，通过编写 Makefile，开发者可以定义各个源代码文件之间的编译顺序，以及当哪些文件改变时需要重新编译哪些目标。Make 工具通过分析这些规则，自动执行必要的构建步骤，极大地提高了软件开发的效率。对于初学者，章节中会介绍 Make 基础语法和工作流程，让读者了解如何设置变量、使用函数、以及如何组织大型项目结构。而对有经验的开发者，本书会深入探讨高级特性，如并行构建、多平台支持和 Makefile 调试技巧，帮助他们优化项目管理和提升团队协作效率。封面的动物——热带非洲森林的 potto（树栖懒猴），象征着 GNU Make 如何帮助项目在看似复杂的构建环境中保持稳定和适应性。通过这本书，读者不仅可以学习到实用的项目管理技术，还能体会到作者将复杂问题简单化处理的理念，从而更好地运用 GNU Make 在自己的项目中实现自动化和标准化。《Managing ProjectsWith GNU Make, Third Edition》是一本结合理论与实践的项目管理指南，旨在帮助读者掌握这一强大的工具，提高开发效率，确保项目的顺利进行。无论是软件工程师、系统管理员还是项目经理，都能从中获益匪浅。

This is the Title of the Book, eMatter Edition

Chapter 2: Rules

a lot more in Chapter 3.) Finally, the .o/.h dependencies are included in the makefile

from a separate file managed by an external program.

Wildcards

A makefile often contains long lists of files. To simplify this process make supports

wildcards (also known as globbing). make’s wildcards are identical to the Bourne

shell’s:

~, *, ?, [...], and [^...]. For instance, *.* expands to all the files containing

a period. A question mark represents any single character, and

[...] represents a

character class. To select the “opposite” (negated) character class use

[^...].

In addition, the tilde (

~) character can be used to represent the current user’s home

directory. A tilde followed by a user name represents that user’s home directory.

Wildcards are automatically expanded by

make whenever a wildcard appears in a tar-

get, prerequisite, or command script context. In other contexts, wildcards can be

expanded explicitly by calling a function. Wildcards can be very useful for creating

more adaptable makefiles. For instance, instead of listing all the files in a program

explicitly, you can use wildcards:

prog: *.c

$(CC) -o $@ $^

It is important to be careful with wildcards, however. It is easy to misuse them as the

following example shows:

*.o: constants.h

The intent is clear: all object files depend on the header file constants.h, but consider

how this expands on a clean directory without any object files:

: constants.h

This is a legal make expression and will not produce an error by itself, but it will also

not provide the dependency the user wants. The proper way to implement this rule is

to perform a wildcard on the source files (since they are always present) and trans-

form that into a list of object files. We will cover this technique when we discuss

make

functions in Chapter 4.

Finally, it is worth noting that wildcard expansion is performed by

make when the

pattern appears as a target or prerequisite. However, when the pattern appears in a

command, the expansion is performed by the subshell. This can occasionally be

important because

make will expand the wildcards immediately upon reading the

makefile, but the shell will expand the wildcards in commands much later when

the command is executed. When a lot of complex file manipulation is being done,

the two wildcard expansions can be quite different.

* In more controlled environments using wildcards to select the files in a program is considered bad practice

because a rogue source file might be accidentally linked into a program.

,ch02.1376 Page 12 Friday, March 25, 2005 1:58 PM

This is the Title of the Book, eMatter Edition

Explicit Rules

Phony Targets

Until now all targets and prerequisites have been files to be created or updated. This

is typically the case, but it is often useful for a target to be just a label representing a

command script. For instance, earlier we noted that a standard first target in many

makefiles is called

all. Targets that do not represent files are known as phony tar-

gets. Another standard phony target is

clean:

rm -f *.o lexer.c

Normally, phony targets will always be executed because the commands associated

with the rule do not create the target name.

It is important to note that

make cannot distinguish between a file target and phony

target. If by chance the name of a phony target exists as a file,

make will associate the

file with the phony target name in its dependency graph. If, for example, the file

clean happened to be created running

make clean would yield the confusing message:

$ make clean

make: `clean' is up to date.

Since most phony targets do not have prerequisites, the clean target would always be

considered up to date and would never execute.

To avoid this problem, GNU

make includes a special target, .PHONY, to tell make that a

target is not a real file. Any target can be declared phony by including it as a prereq-

uisite of

.PHONY:

.PHONY: clean

clean:

rm -f *.o lexer.c

Now make will always execute the commands associated with clean even if a file

named clean exists. In addition to marking a target as always out of date, specifying

that a target is phony tells

make that this file does not follow the normal rules for

making a target file from a source file. Therefore,

make can optimize its normal rule

search to improve performance.

It rarely makes sense to use a phony target as a prerequisite of a real file since the

phony is always out of date and will always cause the target file to be remade. How-

ever, it is often useful to give phony targets prerequisites. For instance, the

all target

is usually given the list of programs to be built:

.PHONY: all

all: bash bashbug

Here the all target creates the bash shell program and the bashbug error reporting

tool.

Phony targets can also be thought of as shell scripts embedded in a makefile. Making

a phony target a prerequisite of another target will invoke the phony target script

,ch02.1376 Page 13 Friday, March 25, 2005 1:58 PM

This is the Title of the Book, eMatter Edition

Chapter 2: Rules

before making the actual target. Suppose we are tight on disk space and before exe-

cuting a disk-intensive task we want to display available disk space. We could write:

.PHONY: make-documentation

make-documentation:

df -k . | awk 'NR = = 2 { printf( "%d available\n", $$4 ) }'

javadoc ...

The problem here is that we may end up specifying the df and awk commands many

times under different targets, which is a maintenance problem since we’ll have to

change every instance if we encounter a

df on another system with a different for-

mat. Instead, we can place the

df line in its own phony target:

.PHONY: make-documentation

make-documentation: df

javadoc ...

.PHONY: df

df:

df -k . | awk 'NR = = 2 { printf( "%d available\n", $$4 ) }'

We can cause make to invoke our df target before generating the documentation by

making

df a prerequisite of make-documentation. This works well because make-

documentation

is also a phony target. Now I can easily reuse df in other targets.

There are a number of other good uses for phony targets.

The output of

make can be confusing to read and debug. There are several reasons for

this: makefiles are written top-down but the commands are executed by

make bot-

tom-up; also, there is no indication which rule is currently being evaluated. The out-

put of

make can be made much easier to read if major targets are commented in the

make output. Phony targets are a useful way to accomplish this. Here is an example

taken from the

bash makefile:

$(Program): build_msg $(OBJECTS) $(BUILTINS_DEP) $(LIBDEP)

$(RM) $@

$(CC) $(LDFLAGS) -o $(Program) $(OBJECTS) $(LIBS)

ls -l $(Program)

size $(Program)

.PHONY: build_msg

build_msg:

@printf "#\n# Building $(Program)\n#\n"

Because the printf is in a phony target, the message is printed immediately before

any prerequisites are updated. If the build message were instead placed as the first

command of the

$(Program) command script, then it would be executed after all

compilation and dependency generation. It is important to note that because phony

targets are always out of date, the phony

build_msg target causes $(Program) to be

regenerated even when it is not out of date. In this case, it seems a reasonable choice

since most of the computation is performed while compiling the object files so only

the final link will always be performed.

,ch02.1376 Page 14 Friday, March 25, 2005 1:58 PM

This is the Title of the Book, eMatter Edition

Explicit Rules

Phony targets can also be used to improve the “user interface” of a makefile. Often

targets are complex strings containing directory path elements, additional filename

components (such as version numbers) and standard suffixes. This can make specify-

ing a target filename on the command line a challenge. The problem can be avoided

by adding a simple phony target whose prerequisite is the actual target file.

By convention there are a set of more or less standard phony targets that many

makefiles include. Table 2-1 lists these standard targets.

The target

TAGS is not really a phony since the output of the ctags and etags pro-

grams is a file named TAGS. It is included here because it is the only standard non-

phony target we know of.

Empty Targets

Empty targets are similar to phony targets in that the target itself is used as a device

to leverage the capabilities of

make. Phony targets are always out of date, so they

always execute and they always cause their dependent (the target associated with the

prerequisite) to be remade. But suppose we have some command, with no output

file, that needs to be performed only occasionally and we don’t want our dependents

updated? For this, we can make a rule whose target is an empty file (sometimes

referred to as a cookie):

prog: size prog.o

$(CC) $(LDFLAGS) -o $@ $^

size: prog.o

size $^

touch size

Notice that the size rule uses touch to create an empty file named size after it com-

pletes. This empty file is used for its timestamp so that

make will execute the size rule

only when prog.o has been updated. Furthermore, the

size prerequisite to prog will

not force an update of prog unless its object file is also newer.

Table 2-1. Standard phony targets

Target Function

all Perform all tasks to build the application

install Create an installation of the application from the compiled binaries

clean Delete the binary files generated from sources

distclean Delete all the generated files that were not in the original source distribution

TAGS Create a tags table for use by editors

info Create GNU info files from their Texinfo sources

check Run any tests associated with this application

,ch02.1376 Page 15 Friday, March 25, 2005 1:58 PM

This is the Title of the Book, eMatter Edition

Chapter 2: Rules

Empty files are particularly useful when combined with the automatic variable $?.

We discuss automatic variables in the section “Automatic Variables,” but a preview

of this variable won’t hurt. Within the command script part of a rule,

make defines

the variable $? to be the set of prerequisites that are newer than the target. Here is

a rule to print all the files that have changed since the last time

make print was

executed:

print: *.[hc]

lpr $?

touch $@

Generally, empty files can be used to mark the last time a particular event has taken

place.

Variables

Let’s look at some of the variables we have been using in our examples. The simplest

ones have the syntax:

$(variable-name)

This indicates that we want to expand the variable whose name is variable-name.

Variables can contain almost any text, and variable names can contain most charac-

ters including punctuation. The variable containing the C compile command is

COMPILE.c, for example. In general, a variable name must be surrounded by $( ) to be

recognized by

make. As a special case, a single character variable name does not

require the parentheses.

A makefile will typically define many variables, but there are also many special vari-

ables defined automatically by

make. Some can be set by the user to control make’s

behavior while others are set by

make to communicate with the user’s makefile.

Automatic Variables

Automatic variables are set by make after a rule is matched. They provide access to

elements from the target and prerequisite lists so you don’t have to explicitly specify

any filenames. They are very useful for avoiding code duplication, but are critical

when defining more general pattern rules (discussed later).

There are six “core” automatic variables:

$@ The filename representing the target.

$% The filename element of an archive member specification.

$< The filename of the first prerequisite.

$? The names of all prerequisites that are newer than the target, separated by

spaces.

,ch02.1376 Page 16 Friday, March 25, 2005 1:58 PM

剩余280页未读，继续阅读

孔令飞

粉丝: 631
资源: 153

GNU Make：项目管理专家罗伯特·梅克伦堡的实用指南

GNU Make项目管理.pdf

GNU Make项目管理(第三版)

GNU make 项目管理（PDF）

gnu make项目管理(第三版) pdf

gnu make 项目管理 pdf

managing projects with gnu make

《gnu make》手册 中文版

gnu make 使用手册(中译版)(于凤昌)翻译

mingw32-make

'gmake' 不是内部或外部命令，也不是可运行的程序 或批处理文件。

最新资源

《gnu make》手册中文版

'gmake' 不是内部或外部命令，也不是可运行的程序或批处理文件。