使用GNU MAKE进行项目管理

5星 · 超过95%的资源需积分: 9 133 浏览量更新于2024-07-31 1 收藏 3.15MB PDF 举报

"Managing ProjectsWith GNU Make, Third Edition by Robert Mecklenburg 是一本关于使用 GNU Make 进行项目管理的书籍，由 O'Reilly Media, Inc. 出版。本书详细介绍了如何利用 GNU Make 工具来组织和管理软件开发项目。自1986年首次出版以来，该书已经更新到了第三版，适用于教育、商业和销售推广使用。在线版本也可在 O'Reilly 的官方网站上获取。编辑由 Andy Oram 担任，生产编辑由 Matt Hutchinson 负责，封面设计由 Edie Freedman 完成，内页设计则由 David Futato 设计。此外，O'Reilly Media, Inc. 的各种标识都是其注册商标。" GNU Make 是一个强大的自动化构建工具，它允许开发者通过编写 Makefile 来定义构建项目的规则和依赖关系。本书深入探讨了 GNU Make 的核心概念和用法，包括： 1. **Makefile基础**：书中介绍了如何创建和编写 Makefile，包括规则定义、目标、依赖项和命令行指令。Makefile 是 GNU Make 的核心，它描述了如何从源代码生成可执行文件或其他输出。 2. **变量与函数**：Makefile 中可以定义变量以存储重复使用的值，并使用内置函数进行字符串处理、列表操作等，提高 Makefile 的可读性和复用性。 3. **规则与依赖**：书中详细阐述了如何定义构建规则，以及如何声明文件之间的依赖关系，以便 Make 自动跟踪文件的更改并仅重新编译必要的部分。 4. **隐含规则**：GNU Make 内置了一系列隐含规则，用于处理常见的文件类型（如 C 和 C++ 代码），减少用户必须显式指定的规则数量。 5. **条件语句和函数**：通过条件语句，可以根据特定条件改变 Makefile 的行为。同时，本书还介绍了如何使用函数进行条件判断和其他逻辑操作。 6. **目标与模式匹配**：模式规则允许使用通配符来定义一组规则，简化 Makefile 编写。例如，`%.o: %.c` 可以表示所有 `.c` 文件如何生成相应的 `.o` 对象文件。 7. **Make 的高级特性**：书中还涵盖了递归 Make、多目标构建、自动变量、伪目标、缓存机制等高级主题，帮助读者更高效地管理复杂项目。 8. **实践案例**：书中可能包含实际项目中的示例，帮助读者理解如何在不同场景下应用 GNU Make，解决实际问题。 9. **调试与优化**：讲解如何调试 Makefile，检查依赖关系，以及如何优化构建过程以提升构建效率。 10. **版本控制集成**：讨论了如何将 GNU Make 与 Git 或其他版本控制系统结合使用，以实现更高效的版本管理和协同工作。 "Managing Projectswith GNU Make, Third Edition" 是一本全面介绍 GNU Make 在项目管理中应用的指南，无论对于初学者还是经验丰富的开发者，都能从中获益，提升项目管理的自动化水平。

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

This is the Title of the Book, eMatter Edition

Finding Files with VPATH and vpath

$^ The filenames of all the prerequisites, separated by spaces. This list has dupli-

cate filenames removed since for most uses, such as compiling, copying, etc.,

duplicates are not wanted.

$+ Similar to $^, this is the names of all the prerequisites separated by spaces,

except that

$+ includes duplicates. This variable was created for specific situa-

tions such as arguments to linkers where duplicate values have meaning.

$* The stem of the target filename. A stem is typically a filename without its suffix.

(We’ll discuss how stems are computed later in the section “Pattern Rules.”) Its

use outside of pattern rules is discouraged.

In addition, each of the above variables has two variants for compatibility with other

makes. One variant returns only the directory portion of the value. This is indicated

by appending a “D” to the symbol,

$(@D), $(<D), etc. The other variant returns only

the file portion of the value. This is indicated by appending an F to the symbol,

$(@F), $(<F), etc. Note that these variant names are more than one character long

and so must be enclosed in parentheses. GNU

make provides a more readable alterna-

tive with the

dir and notdir functions. We will discuss functions in Chapter 4.

Automatic variables are set by

make after a rule has been matched with its target and

prerequisites so the variables are only available in the command script of a rule.

Here is our makefile with explicit filenames replaced by the appropriate automatic

variable.

count_words: count_words.o counter.o lexer.o -lfl

gcc $^ -o $@

count_words.o: count_words.c

gcc -c $<

counter.o: counter.c

gcc -c $<

lexer.o: lexer.c

gcc -c $<

lexer.c: lexer.l

flex -t $< > $@

Finding Files with VPATH and vpath

Our examples so far have been simple enough that the makefile and sources all lived

in a single directory. Real world programs are more complex (when’s the last time

you worked on a single directory project?). Let’s refactor our example and create a

more realistic file layout. We can modify our word counting program by refactoring

main into a function called counter.

#include <lexer.h>

#include <counter.h>

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

剩余277页未读，继续阅读

星空探索

粉丝: 131
资源: 16

使用GNU MAKE进行项目管理

GNU Make项目管理(第三版)

GNU make 项目管理（PDF）

GNU+Make项目管理(第三版)

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

gnu make 项目管理 pdf

managing projects with gnu make

《gnu make》手册 中文版

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

mingw32-make

no rule to make target price'/usr/lib/x86_64-linux-gnu/libpthread.

最新资源

《gnu make》手册中文版