Linux/Unix环境下的make和makefile详解
无论是在Linux还是在Unix环境中，make都是一个非常重要的编译命令。不管是自己进行项目开发还是安装应用软件，我们都经常要用到make或make install。利用make工具，我们可以将大型的开发项目分解成为多个更易于管理的模块，对于一个包括几百个源文件的应用程序，使用make和makefile工具就可以简洁明快地理顺各个源文件之间纷繁复杂的相互关系。而且如此多的源文件，如果每次都要键入gcc命令进行编译的话，那对程序员来说简直就是一场灾难。而make工具则可自动完成编译工作，并且可以只对程序员在上次编译后修改过的部分进行编译。因此，有效的利用make和makefile工具可以大大提高项目开发的效率。同时掌握make和makefile之后，您也不会再面对着Linux下的应用软件手足无措了。
但令人遗憾的是，在许多讲述Linux应用的书籍上都没有详细介绍这个功能强大但又非常复杂的编译工具。在这里我就向大家详细介绍一下make及其描述文件makefile。
Makefile文件
Make工具最主要也是最基本的功能就是通过makefile文件来描述源程序之间的相互关系并自动维护编译工作。而makefile 文件需要按照某种语法进行编写，文件中需要说明如何编译各个源文件并连接生成可执行文件，并要求定义源文件之间的依赖关系。makefile 文件是许多编译器--包括 Windows NT 下的编译器--维护编译信息的常用方法，只是在集成开发环境中，用户通过友好的界面修改 makefile 文件而已。
在 UNIX 系统中，习惯使用 Makefile 作为 makfile 文件。如果要使用其他文件作为 makefile，则可利用类似下面的 make 命令选项指定 makefile 文件：
$ make -f Makefile.debug
例如，一个名为prog的程序由三个C源文件filea.c、fileb.c和filec.c以及库文件LS编译生成，这三个文件还分别包含自己的头文件a.h 、b.h和c.h。通常情况下，C编译器将会输出三个目标文件filea.o、fileb.o和filec.o。假设filea.c和fileb.c都要声明用到一个名为defs的文件，但filec.c不用。即在filea.c和fileb.c里都有这样的声明：
#include "defs"
那么下面的文档就描述了这些文件之间的相互联系:
---------------------------------------------------------
#It is a example for describing makefile
prog : filea.o fileb.o filec.o
cc filea.o fileb.o filec.o -LS -o prog
filea.o : filea.c a.h defs
cc -c filea.c
fileb.o : fileb.c b.h defs
cc -c fileb.c
filec.o : filec.c c.h
cc -c filec.c
----------------------------------------------------------
这个描述文档就是一个简单的makefile文件。
从上面的例子注意到，第一个字符为 # 的行为注释行。第一个非注释行指定prog由三个目标文件filea.o、fileb.o和filec.o链接生成。第三行描述了如何从prog所依赖的文件建立可执行文件。接下来的4、6、8行分别指定三个目标文件，以及它们所依赖的.c和.h文件以及defs文件。而5、7、9行则指定了如何从目标所依赖的文件建立目标。
当filea.c或a.h文件在编译之后又被修改，则 make 工具可自动重新编译filea.o，如果在前后两次编译之间，filea.C 和a.h 均没有被修改，而且 test.o 还存在的话，就没有必要重新编译。这种依赖关系在多源文件的程序编译中尤其重要。通过这种依赖关系的定义，make 工具可避免许多不必要的编译工作。当然，利用 Shell 脚本也可以达到自动编译的效果，但是，Shell 脚本将全部编译任何源文件，包括哪些不必要重新编译的源文件，而 make 工具则可根据目标上一次编译的时间和目标所依赖的源文件的更新时间而自动判断应当编译哪个源文件。
Makefile文件作为一种描述文档一般需要包含以下内容:
◆ 宏定义
◆ 源文件之间的相互依赖关系
◆ 可执行的命令
Makefile中允许使用简单的宏指代源文件及其相关编译信息，在Linux中也称宏为变量。在引用宏时只需在变量前加$符号，但值得注意的是，如果变量名的长度超过一个字符，在引用时就必须加圆括号（）。
下面都是有效的宏引用：
$(CFLAGS)
$2
$Z
$(Z)
其中最后两个引用是完全一致的。
需要注意的是一些宏的预定义变量，在Unix系统中，$*、$@、$?和$<四个特殊宏的值在执行命令的过程中会发生相应的变化，而在GNU make中则定义了更多的预定义变量。关于预定义变量的详细内容，
宏定义的使用可以使我们脱离那些冗长乏味的编译选项，为编写makefile文件带来很大的方便。
---------------------------------------------------------
# Define a macro for the object files
OBJECTS= filea.o fileb.o filec.o
# Define a macro for the library file
LIBES= -LS
# use macros rewrite makefile
prog: $(OBJECTS)
cc $(OBJECTS) $(LIBES) -o prog
……
---------------------------------------------------------
此时如果执行不带参数的make命令，将连接三个目标文件和库文件LS；但是如果在make命令后带有新的宏定义：
make "LIBES= -LL -LS"
则命令行后面的宏定义将覆盖makefile文件中的宏定义。若LL也是库文件，此时make命令将连接三个目标文件以及两个库文件LS和LL。
在Unix系统中没有对常量NULL作出明确的定义，因此我们要定义NULL字符串时要使用下述宏定义：
STRINGNAME=
Make命令
在make命令后不仅可以出现宏定义，还可以跟其他命令行参数，这些参数指定了需要编译的目标文件。其标准形式为：
target1 [target2 …]:[:][dependent1 …][;commands][#…]
[(tab) commands][#…]
方括号中间的部分表示可选项。Targets和dependents当中可以包含字符、数字、句点和"/"符号。除了引用，commands中不能含有"#",也不允许换行。
在通常的情况下命令行参数中只含有一个":"，此时command序列通常和makefile文件中某些定义文件间依赖关系的描述行有关。如果与目标相关连的那些描述行指定了相关的command序列，那么就执行这些相关的command命令，即使在分号和(tab)后面的aommand字段甚至有可能是NULL。如果那些与目标相关连的行没有指定command，那么将调用系统默认的目标文件生成规则。
如果命令行参数中含有两个冒号"::"，则此时的command序列也许会和makefile中所有描述文件依赖关系的行有关。此时将执行那些与目标相关连的描述行所指向的相关命令。同时还将执行build-in规则。
如果在执行command命令时返回了一个非"0"的出错信号，例如makefile文件中出现了错误的目标文件名或者出现了以连字符打头的命令字符串，make操作一般会就此终止，但如果make后带有"-i"参数，则make将忽略此类出错信号。
Make命本身可带有四种参数：标志、宏定义、描述文件名和目标文件名。其标准形式为：
Make [flags] [macro definitions] [targets]
Unix系统下标志位flags选项及其含义为：
-f file 指定file文件为描述文件，如果file参数为"-"符，那么描述文件指向标准输入。如果没有"-f"参数，则系统将默认当前目录下名为makefile或者名为Makefile的文件为描述文件。在Linux中， GNU make 工具在当前工作目录中按照GNUmakefile、makefile、Makefile的顺序搜索 makefile文件。
-i 忽略命令执行返回的出错信息。
-s 沉默模式，在执行之前不输出相应的命令行信息。
-r 禁止使用build-in规则。
-n 非执行模式，输出所有执行命令，但并不执行。
-t 更新目标文件。
-q make操作将根据目标文件是否已经更新返回"0"或非"0"的状态信息。
-p 输出所有宏定义和目标文件描述。
-d Debug模式，输出有关文件和检测时间的详细信息。
Linux下make标志位的常用选项与Unix系统中稍有不同，下面我们只列出了不同部分：
-c dir 在读取 makefile 之前改变到指定的目录dir。
-I dir 当包含其他 makefile文件时，利用该选项指定搜索目录。
-h help文挡，显示所有的make选项。
-w 在处理 makefile 之前和之后，都显示工作目录。
通过命令行参数中的target ，可指定make要编译的目标，并且允许同时定义编译多个目标，操作时按照从左向右的顺序依次编译target选项中指定的目标文件。如果命令行中没有指定目标，则系统默认target指向描述文件中第一个目标文件。
通常，makefile 中还定义有 clean 目标，可用来清除编译过程中的中间文件，例如：
clean:
rm -f *.o
运行 make clean 时，将执行 rm -f *.o 命令，最终删除所有编译过程中产生的所有中间文件。
隐含规则
在make 工具中包含有一些内置的或隐含的规则，这些规则定义了如何从不同的依赖文件建立特定类型的目标。Unix系统通常支持一种基于文件扩展名即文件名后缀的隐含规则。这种后缀规则定义了如何将一个具有特定文件名后缀的文件（例如.c文件），转换成为具有另一种文件名后缀的文件（例如.o文件）：
.c:.o
$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<
系统中默认的常用文件扩展名及其含义为：
.o 目标文件
.c C源文件
.f FORTRAN源文件
.s 汇编源文件
.y Yacc-C源语法
.l Lex源语法
在早期的Unix系统系统中还支持Yacc-C源语法和Lex源语法。在编译过程中，系统会首先在makefile文件中寻找与目标文件相关的.C文件，如果还有与之相依赖的.y和.l文件，则首先将其转换为.c文件后再编译生成相应的.o文件；如果没有与目标相关的.c文件而只有相关的.y文件，则系统将直接编译.y文件。
而GNU make 除了支持后缀规则外还支持另一种类型的隐含规则--模式规则。这种规则更加通用，因为可以利用模式规则定义更加复杂的依赖性规则。模式规则看起来非常类似于正则规则，但在目标名称的前面多了一个 % 号，同时可用来定义目标和依赖文件之间的关系，例如下面的模式规则定义了如何将任意一个 file.c 文件转换为 file.o 文件：
%.c:%.o
$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<
#EXAMPLE#
下面将给出一个较为全面的示例来对makefile文件和make命令的执行进行进一步的说明，其中make命令不仅涉及到了C源文件还包括了Yacc语法。本例选自"Unix Programmer's Manual 7th Edition, Volume 2A" Page 283-284
下面是描述文件的具体内容：
---------------------------------------------------------
#Description file for the Make command
#Send to print
P=und -3 | opr -r2
#The source files that are needed by object files
FILES= Makefile version.c defs main.c donamc.c misc.c file.c \
dosys.c gram.y lex.c gcos.c
#The definitions of object files
OBJECTS= vesion.o main.o donamc.o misc.o file.o dosys.o gram.o
LIBES= -LS
LINT= lnit -p
CFLAGS= -O
make: $(OBJECTS)
cc $(CFLAGS) $(OBJECTS) $(LIBES) -o make
size make
$(OBJECTS): defs
gram.o: lex.c
cleanup:
-rm *.o gram.c
install:
@size make /usr/bin/make
cp make /usr/bin/make ; rm make
#print recently changed files
print: $(FILES)
pr $? | $P
touch print
test:
make -dp | grep -v TIME>1zap
/usr/bin/make -dp | grep -v TIME>2zap
diff 1zap 2zap
rm 1zap 2zap
lint: dosys.c donamc.c file.c main.c misc.c version.c gram.c
$(LINT) dosys.c donamc.c file.c main.c misc.c version.c \
gram.c
rm gram.c
arch:
ar uv /sys/source/s2/make.a $(FILES)
----------------------------------------------------------
通常在描述文件中应象上面一样定义要求输出将要执行的命令。在执行了make命令之后，输出结果为：
$ make
cc -c version.c
cc -c main.c
cc -c donamc.c
cc -c misc.c
cc -c file.c
cc -c dosys.c
yacc gram.y
mv y.tab.c gram.c
cc -c gram.c
cc version.o main.o donamc.o misc.o file.o dosys.o gram.o \
-LS -o make
13188+3348+3044=19580b=046174b
最后的数字信息是执行"@size make"命令的输出结果。之所以只有输出结果而没有相应的命令行，是因为"@size make"命令以"@"起始，这个符号禁止打印输出它所在的命令行。
描述文件中的最后几条命令行在维护编译信息方面非常有用。其中"print"命令行的作用是打印输出在执行过上次"make print"命令后所有改动过的文件名称。系统使用一个名为print的0字节文件来确定执行print命令的具体时间，而宏$?则指向那些在print文件改动过之后进行修改的文件的文件名。如果想要指定执行print命令后，将输出结果送入某个指定的文件，那么就可修改P的宏定义：
make print "P= cat>zap"
在Linux中大多数软件提供的是源代码，而不是现成的可执行文件，这就要求用户根据自己系统的实际情况和自身的需要来配置、编译源程序后，软件才能使用。只有掌握了make工具，才能让我们真正享受到到Linux这个自由软件世界的带给我们无穷乐趣。
GNU make 指南
译者按： 本文是一篇介绍 GNU Make 的文章，读完后读者应该基本掌握了 make 的用法。而 make 是所有想在 Unix （当然也包括 Linux ）系统上编程的用户必须掌握的工具。如果你写的程序中没有用到 make ，则说明你写的程序只是个人的练习程序，不具有任何实用的价值。也许这么说有点 儿偏激，但 make 实在是应该用在任何稍具规模的程序中的。希望本文可以为中国的 Unix 编程初学者提供一点儿有用的资料。中国的 Linux 用户除了学会安装红帽子以外， 实在应该尝试写一些有用的程序。个人想法，大家参考。
--------------------------------------------------------------------------------
C-Scene 题目 #2
多文件项目和 GNU Make 工具
作者: 乔治富特 (Goerge Foot)
电子邮件: george.foot@merton.ox.ac.uk
Occupation: Student at Merton College, Oxford University, England
职业:学生，默尔顿学院,牛津城大学,英格兰
IRC匿名: gfoot
--------------------------------------------------------------------------------
拒绝承诺：作者对于任何因此而对任何事物造成的所有损害（你所拥有或不 拥有的实际的，抽象的，或者虚拟的）。所有的损坏都是你自己的责任，而 与我无关。
所有权： “多文件项目”部分属于作者的财产，版权归乔治富特１９９７年 五月至七月。其它部分属 CScene 财产，版权 CScene １９９７年，保留所有 版权。本 CScene 文章的分发，部分或全部，应依照所有其它 CScene 的文章 的条件来处理。
0) 介绍
~~~~~~~~~~~~~~~
本文将首先介绍为什么要将你的Ｃ源代码分离成几个合理的独立档案，什么时 候需要分，怎么才能分的好。然后将会告诉你 GNU Make 怎样使你的编译和连 接步骤自动化。对于其它 Make 工具的用户来说，虽然在用其它类似工具时要 做适当的调整，本文的内容仍然是非常有用的。如果对你自己的编程工具有怀 疑，可以实际的试一试，但请先阅读用户手册。
1) 多文件项目
~~~~~~~~~~~~~~~~~~~~~~
1.1为什么使用它们?
首先，多文件项目的好处在那里呢？
它们看起来把事情弄的复杂无比。又要 header 文件，又要 extern 声明，而且如果需要查找一个文件，你要在更多的文件里搜索。
但其实我们有很有力的理由支持我们把一个项目分解成小块。当你改 动一行代码，编译器需要全部重新编译来生成一个新的可执行文件。 但如果你的项目是分开在几个小文件里，当你改动其中一个文件的时 候，别的源文件的目标文件(object files)已经存在，所以没有什么 原因去重新编译它们。你所需要做的只是重现编译被改动过的那个文 件，然后重新连接所有的目标文件罢了。在大型的项目中，这意味着 从很长的（几分钟到几小时）重新编译缩短为十几，二十几秒的简单 调整。
只要通过基本的规划，将一个项目分解成多个小文件可使你更加容易 的找到一段代码。很简单，你根据代码的作用把你的代码分解到不同 的文件里。当你要看一段代码时，你可以准确的知道在那个文件中去 寻找它。
从很多目标文件生成一个程序包 (Library)比从一个单一的大目标文件 生成要好的多。当然实际上这是否真是一个优势则是由你所用的系统 来决定的。但是当使用 gcc/ld (一个 GNU C 编译／连接器) 把一个程 序包连接到一个程序时，在连接的过程中，它会尝试不去连接没有使 用到的部分。但它每次只能从程序包中把一个完整的目标文件排除在 外。因此如果你参考一个程序包中某一个目标档中任何一个符号的话， 那么这个目标文件整个都会被连接进来。要是一个程序包被非常充分 的分解了的话，那么经连接后，得到的可执行文件会比从一个大目标 文件组成的程序包连接得到的文件小得多。
又因为你的程序是很模块化的，文件之间的共享部分被减到最少，那 就有很多好处——可以很容易的追踪到臭虫，这些模块经常是可以用 在其它的项目里的，同时别人也可以更容易的理解你的一段代码是干 什么的。当然此外还有许多别的好处……
1.2 何时分解你的项目
很明显，把任何东西都分解是不合理的。象“世界，你们好”这样的 简单程序根本就不能分，因为实在也没什么可分的。把用于测试用的 小程序分解也是没什么意思的。但一般来说，当分解项目有助于布局、 发展和易读性的时候，我都会采取它。在大多数的情况下，这都是适 用的。（所谓“世界，你们好”，既 'hello world' ，只是一个介 绍一种编程语言时惯用的范例程序，它会在屏幕上显示一行 'hello world' 。是最简单的程序。）
如果你需要开发一个相当大的项目，在开始前，应该考虑一下你将 如何实现它，并且生成几个文件（用适当的名字）来放你的代码。 当然，在你的项目开发的过程中，你可以建立新的文件，但如果你 这么做的话，说明你可能改变了当初的想法，你应该想想是否需要 对整体结构也进行相应的调整。
对于中型的项目，你当然也可以采用上述技巧，但你也可以就那么开 始输入你的代码，当你的码多到难以管理的时候再把它们分解成不同 的档案。但以我的经验来说，开始时在脑子里形成一个大概的方案， 并且尽量遵从它，或在开发过程中，随着程序的需要而修改，会使开 发变得更加容易。
1.3 怎样分解项目
先说明，这完全是我个人的意见，你可以（也许你真的会？）用别的 方式来做。这会触动到有关编码风格的问题，而大家从来就没有停止 过在这个问题上的争论。在这里我只是给出我自己喜欢的做法（同时 也给出这么做的原因）：
i) 不要用一个 header 文件指向多个源码文件（例外：程序包 的 header 文件）。用一个 header定义一个源码文件的方式 会更有效，也更容易查寻。否则改变一个源文件的结构（并且 它的 header 文件）就必须重新编译好几个文件。
ii) 如果可以的话，完全可以用超过一个的 header 文件来指向同 一个源码文件。有时将不可公开调用的函数原型，类型定义 等等，从它们的Ｃ源码文件中分离出来是非常有用的。使用一 个 header 文件装公开符号，用另一个装私人符号意味着如果 你改变了这个源码文件的内部结构，你可以只是重新编译它而 不需要重新编译那些使用它的公开 header 文件的其它的源文 件。
iii) 不要在多个 header 文件中重复定义信息。 如果需要， 在其中一个 header 文件里 #include 另一个，但 是不要重复输入相同的 header 信息两次。原因是如果你以后改 变了这个信息，你只需要把它改变一次，不用搜索并改变另外一 个重复的信息。
iv) 在每一个源码文件里， #include 那些声明了源码文件中的符 号的所有 header 文件。这样一来，你在源码文件和 header 文件对某些函数做出的矛盾声明可以比较容易的被编译器发现。
1.4 对于常见错误的注释
a) 定义符 (Identifier) 在源码文件中的矛盾：在Ｃ里，变量和函数的缺 省状态是公用的。因此，任何Ｃ源码档案都可以引用存在于其它源 码档中的通用 (global) 函数和通用变量，既使这个档案没有那个变 量或函数的声明或原型。因此你必须保证在不同的两个档案里不能 用同一个符号名称，否则会有连接错误或者在编译时会有警告。
一种避免这种错误的方法是在公用的符号前加上跟其所在源文件有 关的前缀。比如：所有在 gfx.c 里的函数都加上前缀“gfx_”。如果 你很小心的分解你的程序，使用有意义的函数名称，并且不是过分 使用通用变量，当然这根本就不是问题。
要防止一个符号在它被定义的源文件以外被看到，可在它的定义前 加上关键字“static”。这对只在一个档案内部使用，其它档案都 都不会用到的简单函数是很有用的。
b) 多次定义的符号： header 档会被逐字的替换到你源文件里 #include 的位置的。因此，如果 header 档被 #include 到一个以上的源文件 里，这个 header 档中所有的定义就会出现在每一个有关的源码文件 里。这会使它们里的符号被定义一次以上，从而出现连接错误（见 上）。
解决方法： 不要在 header 档里定义变量。你只需要在 header 档里声明它们然后在适当的Ｃ源码文件（应该 #include 那个 header 档的那个）里定义它们（一次）。对于初学者来说，定义和声明是 很容易混淆的。声明的作用是告诉编译器其所声明的符号应该存在， 并且要有所指定的类型。但是，它并不会使编译器分配贮存空间。 而定义的做用是要求编译器分配贮存空间。当做一个声明而不是做 定义的时候，在声明前放一个关键字“extern”。
例如，我们有一个叫“counter”的变量，如果想让它成为公用的， 我们在一个源码程序（只在一个里面）的开始定义它：“int counter;”，再在相关的 header 档里声明它：“extern int counter;”。
函数原型里隐含着 extern 的意思，所以不需顾虑这个问题。
c) 重复定义，重复声明，矛盾类型：
请考虑如果在一个Ｃ源码文件中 #include 两个档 a.h 和 b.h， 而 a.h 又 #include 了 b.h 档（原因是 b.h 档定义了一些 a.h 需要的类型），会发生什么事呢？这时该Ｃ源码文件 #include 了 b.h 两次。因此每一个在 b.h 中的 #define 都发生了两次，每一 个声明发生了两次，等等。理论上，因为它们是完全一样的拷贝， 所以应该不会有什么问题，但在实际应用上，这是不符合Ｃ的语法 的，可能在编译时出现错误，或至少是警告。
解决的方法是要确定每一个 header 档在任一个源码文件中只被包 含了一次。我们一般是用预处理器来达到这个目的的。当我们进入 每一个 header 档时，我们为这个 header 档 #define 一个巨集 指令。只有在这个巨集指令没有被定义的前提下，我们才真正使用 该 header 档的主体。在实际应用上，我们只要简单的把下面一段 码放在每一个 header 档的开始部分：
#ifndef FILENAME_H
#define FILENAME_H
然后把下面一行码放在最后：
#endif
用 header 档的档名（大写的）代替上面的 FILENAME_H，用底线 代替档名中的点。有些人喜欢在 #endif 加上注释来提醒他们这个 #endif 指的是什么。例如：
#endif /* #ifndef FILENAME_H */
我个人没有这个习惯，因为这其实是很明显的。当然这只是各人的 风格不同，无伤大雅。
你只需要在那些有编译错误的 header 档中加入这个技巧，但在所 有的 header 档中都加入也没什么损失，到底这是个好习惯。
1.5 重新编译一个多文件项目
清楚的区别编译和连接是很重要的。编译器使用源码文件来产生某种 形式的目标文件(object files)。在这个过程中，外部的符号参考并 没有被解释或替换。然后我们使用连接器来连接这些目标文件和一些 标准的程序包再加你指定的程序包，最后连接生成一个可执行程序。 在这个阶段，一个目标文件中对别的文件中的符号的参考被解释，并 报告不能被解释的参考，一般是以错误信息的形式报告出来。
基本的步骤就应该是，把你的源码文件一个一个的编译成目标文件的格 式，最后把所有的目标文件加上需要的程序包连接成一个可执行文件。 具体怎么做是由你的编译器决定的。这里我只给出 gcc （GNU C 编译 器）的有关命令，这些有可能对你的非 gcc 编译器也适用。
gcc 是一个多目标的工具。它在需要的时候呼叫其它的元件（预处理 程序，编译器，组合程序，连接器）。具体的哪些元件被呼叫取决于 输入文件的类型和你传递给它的开关。
一般来说，如果你只给它Ｃ源码文件，它将预处理，编译，组合所有 的文件，然后把所得的目标文件连接成一个可执行文件（一般生成的 文件被命名为 a.out ）。你当然可以这么做，但这会破坏很多我们 把一个项目分解成多个文件所得到的好处。
如果你给它一个 -c 开关，gcc 只把给它的文件编译成目标文件， 用源码文件的文件名命名但把其后缀由“.c”或“.cc”变成“.o”。 如果你给它的是一列目标文件， gcc 会把它们连接成可执行文件， 缺省文件名是 a.out 。你可以改变缺省名，用开关 -o 后跟你指定 的文件名。
因此，当你改变了一个源码文件后，你需要重新编译它： 'gcc -c filename.c' 然后重新连接你的项目： 'gcc -o exec_filename *.o'。 如果你改变了一个 header 档，你需要重新编译所有 #include 过 这个档的源码文件，你可以用 'gcc -c file1.c file2.c file3.c' 然后象上边一样连接。
当然这么做是很繁琐的，幸亏我们有些工具使这个步骤变得简单。 本文的第二部分就是介绍其中的一件工具：GNU Make 工具。
（好家伙，现在才开始见真章。您学到点儿东西没？）
2) GNU Make 工具
~~~~~~~~~~~~~~~~
2.1 基本 makefile 结构
GNU Make 的主要工作是读进一个文本文件， makefile 。这个文 件里主要是有关哪些文件（‘target’目的文件）是从哪些别的 文件（‘dependencies’依靠文件）中产生的，用什么命令来进行 这个产生过程。有了这些信息， make 会检查磁碟上的文件，如果 目的文件的时间戳（该文件生成或被改动时的时间）比至少它的一 个依靠文件旧的话， make 就执行相应的命令，以便更新目的文件。 （目的文件不一定是最后的可执行档，它可以是任何一个文件。）
makefile 一般被叫做“makefile”或“Makefile”。当然你可以 在 make 的命令行指定别的文件名。如果你不特别指定，它会寻 找“makefile”或“Makefile”，因此使用这两个名字是最简单 的。
一个 makefile 主要含有一系列的规则，如下：
: ...
(tab)
(tab)
.
.
.
例如，考虑以下的 makefile ：
=== makefile 开始 ===
myprog : foo.o bar.o
gcc foo.o bar.o -o myprog
foo.o : foo.c foo.h bar.h
gcc -c foo.c -o foo.o
bar.o : bar.c bar.h
gcc -c bar.c -o bar.o
=== makefile 结束 ===
这是一个非常基本的 makefile —— make 从最上面开始，把上 面第一个目的，‘myprog’，做为它的主要目标（一个它需要保 证其总是最新的最终目标）。给出的规则说明只要文件‘myprog’ 比文件‘foo.o’或‘bar.o’中的任何一个旧，下一行的命令将 会被执行。
但是，在检查文件 foo.o 和 bar.o 的时间戳之前，它会往下查 找那些把 foo.o 或 bar.o 做为目标文件的规则。它找到的关于 foo.o 的规则，该文件的依靠文件是 foo.c, foo.h 和 bar.h 。 它从下面再找不到生成这些依靠文件的规则，它就开始检查磁碟 上这些依靠文件的时间戳。如果这些文件中任何一个的时间戳比 foo.o 的新，命令 'gcc -o foo.o foo.c' 将会执行，从而更新 文件 foo.o 。
接下来对文件 bar.o 做类似的检查，依靠文件在这里是文件 bar.c 和 bar.h 。
现在， make 回到‘myprog’的规则。如果刚才两个规则中的任 何一个被执行，myprog 就需要重建（因为其中一个 .o 档就会比 ‘myprog’新），因此连接命令将被执行。
希望到此，你可以看出使用 make 工具来建立程序的好处——前 一章中所有繁琐的检查步骤都由 make 替你做了：检查时间戳。 你的源码文件里一个简单改变都会造成那个文件被重新编译（因 为 .o 文件依靠 .c 文件），进而可执行文件被重新连接（因为 .o 文件被改变了）。其实真正的得益是在当你改变一个 header 档的时候——你不再需要记住那个源码文件依靠它，因为所有的 资料都在 makefile 里。 make 会很轻松的替你重新编译所有那 些因依靠这个 header 文件而改变了的源码文件，如有需要，再 进行重新连接。
当然，你要确定你在 makefile 中所写的规则是正确无误的，只 列出那些在源码文件中被 #include 的 header 档……
2.2 编写 make 规则 (Rules)
最明显的（也是最简单的）编写规则的方法是一个一个的查 看源码文件，把它们的目标文件做为目的，而Ｃ源码文件和被它 #include 的 header 档做为依靠文件。但是你也要把其它被这些 header 档 #include 的 header 档也列为依靠文件，还有那些被 包括的文件所包括的文件……然后你会发现要对越来越多的文件 进行管理，然后你的头发开始脱落，你的脾气开始变坏，你的脸 色变成菜色，你走在路上开始跟电线杆子碰撞，终于你捣毁你的 电脑显示器，停止编程。到低有没有些容易点儿的方法呢？
当然有！向编译器要！在编译每一个源码文件的时候，它实在应 该知道应该包括什么样的 header 档。使用 gcc 的时候，用 -M 开关，它会为每一个你给它的Ｃ文件输出一个规则，把目标文件 做为目的，而这个Ｃ文件和所有应该被 #include 的 header 文 件将做为依靠文件。注意这个规则会加入所有 header 文件，包 括被角括号(`<', `>')和双引号(`"')所包围的文件。其实我们可以 相当肯定系统 header 档（比如 stdio.h, stdlib.h 等等）不会 被我们更改，如果你用 -MM 来代替 -M 传递给 gcc，那些用角括 号包围的 header 档将不会被包括。（这会节省一些编译时间）
由 gcc 输出的规则不会含有命令部分；你可以自己写入你的命令 或者什么也不写，而让 make 使用它的隐含的规则（参考下面的 2.4 节）。
2.3 Makefile 变量
上面提到 makefiles 里主要包含一些规则。它们包含的其它的东 西是变量定义。
makefile 里的变量就像一个环境变量(environment variable)。 事实上，环境变量在 make 过程中被解释成 make 的变量。这些 变量是大小写敏感的，一般使用大写字母。它们可以从几乎任何 地方被引用，也可以被用来做很多事情，比如：
i) 贮存一个文件名列表。在上面的例子里，生成可执行文件的 规则包含一些目标文件名做为依靠。在这个规则的命令行 里同样的那些文件被输送给 gcc 做为命令参数。如果在这 里使用一个变数来贮存所有的目标文件名，加入新的目标 文件会变的简单而且较不易出错。
ii) 贮存可执行文件名。如果你的项目被用在一个非 gcc 的系 统里，或者如果你想使用一个不同的编译器，你必须将所 有使用编译器的地方改成用新的编译器名。但是如果使用一 个变量来代替编译器名，那么你只需要改变一个地方，其 它所有地方的命令名就都改变了。
iii) 贮存编译器旗标。假设你想给你所有的编译命令传递一组 相同的选项（例如 -Wall -O -g）；如果你把这组选项存 入一个变量，那么你可以把这个变量放在所有呼叫编译器 的地方。而当你要改变选项的时候，你只需在一个地方改 变这个变量的内容。
要设定一个变量，你只要在一行的开始写下这个变量的名字，后 面跟一个 = 号，后面跟你要设定的这个变量的值。以后你要引用 这个变量，写一个 $ 符号，后面是围在括号里的变量名。比如在 下面，我们把前面的 makefile 利用变量重写一遍：
=== makefile 开始 ===
OBJS = foo.o bar.o
CC = gcc
CFLAGS = -Wall -O -g
myprog : $(OBJS)
$(CC) $(OBJS) -o myprog
foo.o : foo.c foo.h bar.h
$(CC) $(CFLAGS) -c foo.c -o foo.o
bar.o : bar.c bar.h
$(CC) $(CFLAGS) -c bar.c -o bar.o
=== makefile 结束 ===
还有一些设定好的内部变量，它们根据每一个规则内容定义。三个 比较有用的变量是 $@, $< 和 $^ （这些变量不需要括号括住）。 $@ 扩展成当前规则的目的文件名， $< 扩展成依靠列表中的第 一个依靠文件，而 $^ 扩展成整个依靠的列表（除掉了里面所有重 复的文件名）。利用这些变量，我们可以把上面的 makefile 写成：
=== makefile 开始 ===
OBJS = foo.o bar.o
CC = gcc
CFLAGS = -Wall -O -g
myprog : $(OBJS)
$(CC) $^ -o $@
foo.o : foo.c foo.h bar.h
$(CC) $(CFLAGS) -c $< -o $@
bar.o : bar.c bar.h
$(CC) $(CFLAGS) -c $< -o $@
=== makefile 结束 ===
你可以用变量做许多其它的事情，特别是当你把它们和函数混合 使用的时候。如果需要更进一步的了解，请参考 GNU Make 手册。 ('man make', 'man makefile')
2.4 隐含规则 (Implicit Rules)
请注意，在上面的例子里，几个产生 .o 文件的命令都是一样的。 都是从 .c 文件和相关文件里产生 .o 文件，这是一个标准的步 骤。其实 make 已经知道怎么做——它有一些叫做隐含规则的内 置的规则，这些规则告诉它当你没有给出某些命令的时候，应该 怎么办。
如果你把生成 foo.o 和 bar.o 的命令从它们的规则中删除， make 将会查找它的隐含规则，然后会找到一个适当的命令。它的命令会 使用一些变量，因此你可以按照你的想法来设定它：它使用变量 CC 做为编译器（象我们在前面的例子），并且传递变量 CFLAGS （给 C 编译器，C++ 编译器用 CXXFLAGS ），CPPFLAGS （ C 预 处理器旗标）， TARGET_ARCH （现在不用考虑这个），然后它加 入旗标 '-c' ，后面跟变量 $< （第一个依靠名），然后是旗 标 '-o' 跟变量 $@ （目的文件名）。一个Ｃ编译的具体命令将 会是：
$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c $< -o $@
当然你可以按照你自己的需要来定义这些变量。这就是为什么用 gcc 的 -M 或 -MM 开关输出的码可以直接用在一个 makefile 里。
2.5 假象目的 (Phony Targets)
假设你的一个项目最后需要产生两个可执行文件。你的主要目标 是产生两个可执行文件，但这两个文件是相互独立的——如果一 个文件需要重建，并不影响另一个。你可以使用“假象目的”来 达到这种效果。一个假象目的跟一个正常的目的几乎是一样的， 只是这个目的文件是不存在的。因此， make 总是会假设它需要 被生成，当把它的依赖文件更新后，就会执行它的规则里的命令 行。
如果在我们的 makefile 开始处输入：
all : exec1 exec2
其中 exec1 和 exec2 是我们做为目的的两个可执行文件。 make 把这个 'all' 做为它的主要目的，每次执行时都会尝试把 'all' 更新。但既然这行规则里没有哪个命令来作用在一个叫 'all' 的 实际文件（事实上 all 并不会在磁碟上实际产生），所以这个规 则并不真的改变 'all' 的状态。可既然这个文件并不存在，所以 make 会尝试更新 all 规则，因此就检查它的依靠 exec1, exec2 是否需要更新，如果需要，就把它们更新，从而达到我们的目的。
假象目的也可以用来描述一组非预设的动作。例如，你想把所有由 make 产生的文件删除，你可以在 makefile 里设立这样一个规则：
veryclean :
rm *.o
rm myprog
前提是没有其它的规则依靠这个 'veryclean' 目的，它将永远 不会被执行。但是，如果你明确的使用命令 'make veryclean' ， make 会把这个目的做为它的主要目标，执行那些 rm 命令。
如果你的磁碟上存在一个叫 veryclean 文件，会发生什么事？这 时因为在这个规则里没有任何依靠文件，所以这个目的文件一定是 最新的了（所有的依靠文件都已经是最新的了），所以既使用户明 确命令 make 重新产生它，也不会有任何事情发生。解决方法是标 明所有的假象目的（用 .PHONY），这就告诉 make 不用检查它们 是否存在于磁碟上，也不用查找任何隐含规则，直接假设指定的目 的需要被更新。在 makefile 里加入下面这行包含上面规则的规则：
.PHONY : veryclean
就可以了。注意，这是一个特殊的 make 规则，make 知道 .PHONY 是一个特殊目的，当然你可以在它的依靠里加入你想用的任何假象 目的，而 make 知道它们都是假象目的。
2.6 函数 (Functions)
makefile 里的函数跟它的变量很相似——使用的时候，你用一个 $ 符号跟开括号，函数名，空格后跟一列由逗号分隔的参数，最后 用关括号结束。例如，在 GNU Make 里有一个叫 'wildcard' 的函 数，它有一个参数，功能是展开成一列所有符合由其参数描述的文 件名，文件间以空格间隔。你可以像下面所示使用这个命令：
SOURCES = $(wildcard *.c)
这行会产生一个所有以 '.c' 结尾的文件的列表，然后存入变量 SOURCES 里。当然你不需要一定要把结果存入一个变量。
另一个有用的函数是 patsubst （ patten substitude, 匹配替 换的缩写）函数。它需要３个参数——第一个是一个需要匹配的 式样，第二个表示用什么来替换它，第三个是一个需要被处理的 由空格分隔的字列。例如，处理那个经过上面定义后的变量，
OBJS = $(patsubst %.c,%.o,$(SOURCES))
这行将处理所有在 SOURCES 字列中的字（一列文件名），如果它的 结尾是 '.c' ，就用 '.o' 把 '.c' 取代。注意这里的 % 符号将匹 配一个或多个字符，而它每次所匹配的字串叫做一个‘柄’(stem) 。 在第二个参数里， % 被解读成用第一参数所匹配的那个柄。
2.7 一个比较有效的 makefile
利用我们现在所学的，我们可以建立一个相当有效的 makefile 。 这个 makefile 可以完成大部分我们需要的依靠检查，不用做太大 的改变就可直接用在大多数的项目里。
首先我们需要一个基本的 makefile 来建我们的程序。我们可以让 它搜索当前目录，找到源码文件，并且假设它们都是属于我们的项 目的，放进一个叫 SOURCES 的变量。这里如果也包含所有的 *.cc 文件，也许会更保险，因为源码文件可能是 C++ 码的。
SOURCES = $(wildcard *.c *.cc)
利用 patsubst ，我们可以由源码文件名产生目标文件名，我们需 要编译出这些目标文件。如果我们的源码文件既有 .c 文件，也有 .cc 文件，我们需要使用相嵌的 patsubst 函数呼叫：
OBJS = $(patsubst %.c,%.o,$(patsubst %.cc,%.o,$(SOURCES)))
最里面一层 patsubst 的呼叫会对 .cc 文件进行后缀替代，产生的结 果被外层的 patsubst 呼叫处理，进行对 .c 文件后缀的替代。
现在我们可以设立一个规则来建可执行文件：
myprog : $(OBJS)
gcc -o myprog $(OBJS)
进一步的规则不一定需要， gcc 已经知道怎么去生成目标文件 (object files) 。下面我们可以设定产生依靠信息的规则：
depends : $(SOURCES)
gcc -M $(SOURCES) > depends
在这里如果一个叫 'depends' 的文件不存在，或任何一个源码文件 比一个已存在的 depends 文件新，那么一个 depends 文件会被生 成。depends 文件将会含有由 gcc 产生的关于源码文件的规则（注 意 -M 开关）。现在我们要让 make 把这些规则当做 makefile 档 的一部分。这里使用的技巧很像 C 语言中的 #include 系统——我 们要求 make 把这个文件 include 到 makefile 里，如下：
include depends
GNU Make 看到这个，检查 'depends' 目的是否更新了，如果没有， 它用我们给它的命令重新产生 depends 档。然后它会把这组（新） 规则包含进来，继续处理最终目标 'myprog' 。当看到有关 myprog 的规则，它会检查所有的目标文件是否更新——利用 depends 文件 里的规则，当然这些规则现在已经是更新过的了。
这个系统其实效率很低，因为每当一个源码文件被改动，所有的源码 文件都要被预处理以产生一个新的 'depends' 文件。而且它也不是 100% 的安全，这是因为当一个 header 档被改动，依靠信息并不会 被更新。但就基本工作来说，它也算相当有用的了。
2.8 一个更好的 makefile
这是一个我为我大多数项目设计的 makefile 。它应该可以不需要修 改的用在大部分项目里。我主要把它用在 djgpp 上，那是一个 DOS 版的 gcc 编译器。因此你可以看到执行的命令名、 'alleg' 程序包、 和 RM -F 变量都反映了这一点。
=== makefile 开始 ===
######################################
#
# Generic makefile
#
# by George Foot
# email: george.foot@merton.ox.ac.uk
#
# Copyright (c) 1997 George Foot
# All rights reserved.
# 保留所有版权
#
# No warranty, no liability;
# you use this at your own risk.
# 没保险，不负责
# 你要用这个，你自己担风险
#
# You are free to modify and
# distribute this without giving
# credit to the original author.
# 你可以随便更改和散发这个文件
# 而不需要给原作者什么荣誉。
# （你好意思？）
#
######################################
### Customising
# 用户设定
#
# Adjust the following if necessary; EXECUTABLE is the target
# executable's filename, and LIBS is a list of libraries to link in
# (e.g. alleg, stdcx, iostr, etc). You can override these on make's
# command line of course, if you prefer to do it that way.
#
# 如果需要，调整下面的东西。 EXECUTABLE 是目标的可执行文件名， LIBS
# 是一个需要连接的程序包列表（例如 alleg, stdcx, iostr 等等）。当然你
# 可以在 make 的命令行覆盖它们，你愿意就没问题。
#
EXECUTABLE := mushroom.exe
LIBS := alleg
# Now alter any implicit rules' variables if you like, e.g.:
#
# 现在来改变任何你想改动的隐含规则中的变量，例如
CFLAGS := -g -Wall -O3 -m486
CXXFLAGS := $(CFLAGS)
# The next bit checks to see whether rm is in your djgpp bin
# directory; if not it uses del instead, but this can cause (harmless)
# `File not found' error messages. If you are not using DOS at all,
# set the variable to something which will unquestioningly remove
# files.
#
# 下面先检查你的 djgpp 命令目录下有没有 rm 命令，如果没有，我们使用
# del 命令来代替，但有可能给我们 'File not found' 这个错误信息，这没
# 什么大碍。如果你不是用 DOS ，把它设定成一个删文件而不废话的命令。
# （其实这一步在 UNIX 类的系统上是多余的，只是方便 DOS 用户。 UNIX
# 用户可以删除这５行命令。）
ifneq ($(wildcard $(DJDIR)/bin/rm.exe),)
RM-F := rm -f
else
RM-F := del
endif
# You shouldn't need to change anything below this point.
#
# 从这里开始，你应该不需要改动任何东西。（我是不太相信，太ＮＢ了！）
SOURCE := $(wildcard *.c) $(wildcard *.cc)
OBJS := $(patsubst %.c,%.o,$(patsubst %.cc,%.o,$(SOURCE)))
DEPS := $(patsubst %.o,%.d,$(OBJS))
MISSING_DEPS := $(filter-out $(wildcard $(DEPS)),$(DEPS))
MISSING_DEPS_SOURCES := $(wildcard $(patsubst %.d,%.c,$(MISSING_DEPS)) \
$(patsubst %.d,%.cc,$(MISSING_DEPS)))
CPPFLAGS += -MD
.PHONY : everything deps objs clean veryclean rebuild
everything : $(EXECUTABLE)
deps : $(DEPS)
objs : $(OBJS)
clean :
@$(RM-F) *.o
@$(RM-F) *.d
veryclean: clean
@$(RM-F) $(EXECUTABLE)
rebuild: veryclean everything
ifneq ($(MISSING_DEPS),)
$(MISSING_DEPS) :
@$(RM-F) $(patsubst %.d,%.o,$@)
endif
-include $(DEPS)
$(EXECUTABLE) : $(OBJS)
gcc -o $(EXECUTABLE) $(OBJS) $(addprefix -l,$(LIBS))
=== makefile 结束 ===
有几个地方值得解释一下的。首先，我在定义大部分变量的时候使 用的是 := 而不是 = 符号。它的作用是立即把定义中参考到的函 数和变量都展开了。如果使用 = 的话，函数和变量参考会留在那 儿，就是说改变一个变量的值会导致其它变量的值也被改变。例 如：
A = foo
B = $(A)
# 现在 B 是 $(A) ，而 $(A) 是 'foo' 。
A = bar
# 现在 B 仍然是 $(A) ，但它的值已随着变成 'bar' 了。
B := $(A)
# 现在 B 的值是 'bar' 。
A = foo
# B 的值仍然是 'bar' 。
make 会忽略在 # 符号后面直到那一行结束的所有文字。
ifneg...else...endif 系统是 makefile 里让某一部分码有条件的 失效／有效的工具。 ifeq 使用两个参数，如果它们相同，它把直 到 else （或者 endif ，如果没有 else 的话）的一段码加进 makefile 里；如果不同，把 else 到 endif 间的一段码加入 makefile （如果有 else ）。 ifneq 的用法刚好相反。
'filter-out' 函数使用两个用空格分开的列表，它把第二列表中所 有的存在于第一列表中的项目删除。我用它来处理 DEPS 列表，把所 有已经存在的项目都删除，而只保留缺少的那些。
我前面说过， CPPFLAGS 存有用于隐含规则中传给预处理器的一些 旗标。而 -MD 开关类似 -M 开关，但是从源码文件 .c 或 .cc 中 形成的文件名是使用后缀 .d 的（这就解释了我形成 DEPS 变量的 步骤）。DEPS 里提到的文件后来用 '-include' 加进了 makefile 里，它隐藏了所有因文件不存在而产生的错误信息。
如果任何依靠文件不存在， makefile 会把相应的 .o 文件从磁碟 上删除，从而使得 make 重建它。因为 CPPFLAGS 指定了 -MD ， 它的 .d 文件也被重新产生。
最后， 'addprefix' 函数把第二个参数列表的每一项前缀上第一 个参数值。
这个 makefile 的那些目的是（这些目的可以传给 make 的命令行 来直接选用）：
everything:（预设） 更新主要的可执行程序，并且为每一个 源码文件生成或更新一个 '.d' 文件和一个 '.o' 文件。
deps: 只是为每一个源码程序产生或更新一个 '.d' 文件。
objs: 为每一个源码程序生成或更新 '.d' 文件和目标文件。
clean: 删除所有中介／依靠文件（ *.d 和 *.o ）。
veryclean: 做 `clean' 和删除可执行文件。
rebuild: 先做 `veryclean' 然后 `everything' ；既完全重建。
除了预设的 everything 以外，这里头只有 clean ， veryclean ， 和 rebuild 对用户是有意义的。
我还没有发现当给出一个源码文件的目录，这个 makefile 会失败的 情况，除非依靠文件被弄乱。如果这种弄乱的情况发生了，只要输入 `make clean' ，所有的目标文件和依靠文件会被删除，问题就应该 被解决了。当然，最好不要把它们弄乱。如果你发现在某种情况下这 个 makefile 文件不能完成它的工作，请告诉我，我会把它整好的。
3 总结
~~~~~~~~~~~~~~~
我希望这篇文章足够详细的解释了多文件项目是怎么运作的，也说明了 怎样安全而合理的使用它。到此，你应该可以轻松的利用 GNU Make 工 具来管理小型的项目，如果你完全理解了后面几个部分的话，这些对于 你来说应该没什么困难。
GNU Make 是一件强大的工具，虽然它主要是用来建立程序，它还有很多 别的用处。如果想要知道更多有关这个工具的知识，它的句法，函数， 和许多别的特点，你应该参看它的参考文件 (info pages, 别的 GNU 工具也一样，看它们的 info pages. )。
由 jily 发表于 November 12, 2004 08:55 AM
Makefile解读
http://www.chinaunix.net 作者:雪中独行 发表于：2003-02-09 12:27:09
原文出自：http://www.linuxforum.net
作者：jkl
==========================================
Makefile 初探
==========================================
Linux的内核配置文件有两个，一个是隐含的.config文件，嵌入到主Makefile中；另一个是include/linux/autoconf.h，嵌入到各个c源文件中，它们由make config、make menuconfig、make xconfig这些过程创建。几乎所有的源文件都会通过linux/config.h而嵌入autoconf.h，如果按照通常方法建立文件依赖关系(.depend)，只要更新过autoconf.h，就会造成所有源代码的重新编绎。
为了优化make过程，减少不必要的重新编绎，Linux开发了专用的mkdep工具，用它来取代gcc来生成.depend文件。mkdep在处理源文件时，忽略linux/config.h这样的头文件，识别源文件宏指令中具有＂CONFIG_＂特征的行。例如，如果有＂#ifdef CONFIG_SMP＂这样的行，它就会在.depend文件中输出$(wildcard /usr/src/linux/include/config/smp.h)。
include/config/下的文件是另一个工具split-include从autoconf.h中生成，它利用autoconf.h中的CONFIG_标记，生成与mkdep相对应的文件。例如，如果autoconf.h中有＂#undef CONFIG_SMP＂这一行，它就生成include/config/smp.h文件，内容为＂#undef CONFIG_SMP＂。这些文件名只在.depend文件中出现，内核源文件是不会嵌入它们的。每配置一次内核，运行split-include一次。split-include会检查旧的子文件的内容，确定是不是要更新它们。这样，不管autoconf.h修改日期如何，只要其配置不变，make就不会重新编绎内核。
如果系统的编绎选项发生了变化，Linux也能进行增量编绎。为了做到这一点，make每编绎一个源文件时生成一个flags文件。例如编绎sched.c时，会在相同的目录下生成隐含的.sched.o.flags文件。它是Makefile的一个片断，当make进入某个子目录编绎时，会搜索其中的flags文件，将它们嵌入到Makefile中。这些flags代码测试当前的编绎选项与原来的是不是相同，如果相同，就将自已对应的目标文件加入FILES_FLAGS_UP_TO_DATE列表，然后，系统从编绎对象表中删除它们，得到FILES_FLAGS_CHANGED列表，最后，将它们设为目标进行更新。
下一步准备逐步深入的剖析Makefile代码。
==========================================
Makefile解读之二: sub-make
==========================================
Linux各级内核源代码的子目录下都有Makefile，大多数Makefile要嵌入主目录下的Rule.make，Rule.make将识别各个Makefile中所定义的一些变量。变量obj-y表示需要编绎到内核中的目标文件名集合，定义O_TARGET表示将obj-y连接为一个O_TARGET名称的目标文件，定义L_TARGET表示将obj-y合并为一个L_TARGET名称的库文件。同样obj-m表示需要编绎成模块的目标文件名集合。如果还需进行子目录make，则需要定义subdir-y和subdir-m。在Makefile中，用＂obj-$(CONFIG_BINFMT_ELF) += binfmt_elf.o＂和＂subdir-$(CONFIG_EXT2_FS) += ext2＂这种形式自动为obj-y、obj-m、subdir-y、subdir-m添加文件名。有时，情况没有这么单纯，还需要使用条件语句个别对待。Makefile中还有其它一些变量，如mod-subdirs定义了subdir-m以外的所有模块子目录。
Rules.make是如何使make进入子目录的呢? 先来看subdir-y是如何处理的，在Rules.make中，先对subdir-y中的每一个文件名加上前缀＂_subdir_＂再进行排序生成subdir-list集合，再以它作为目标集，对其中每一个目标产生一个子make，同时将目标名的前缀去掉得到子目录名，作为子make的起始目录参数。subdir-m与subdir-y类似，但情况稍微复杂一些。由于subdir-y中可能有模块定义，因此利用mod-subdirs变量将subdir-y中模块目录提取出来，再与subdir-m合成一个大的MOD_SUB_DIRS集合。subdir-m的目标所用的前缀是＂_modsubdir_＂。
一点说明，子目录中的Makefile与Rules.make都没有嵌入.config文件，它是通过主Makefile向下传递MAKEFILES变量完成的。MAKEFILES是make自已识别的一个变量，在执行新的Makefile之前，make会首先加载MAKEFILES所指的文件。在主Makefile中它即指向.config。
==========================================
Makefile解读之三: 模块的版本化处理
==========================================
模块的版本化是内核与模块接口之间进行严格类型匹配的一种方法。当内核配置了CONFIG_MODVERSIONS之后，make dep操作会在include/linux/modules/目录下为各级Makefile中export-objs变量所对应的源文件生成扩展名为.ver的文件。
例如对于kernel/ksyms.c，make用以下命令生成对应的ksyms.ver：
gcc -E -D__KERNEL__ -D__GENKSYMS__ ksyms.c | /sbin/genksyms -k 2.4.1 > ksyms.ver
-D__GENKSYMS__的作用是使ksyms.c中的EXPORT_SYMBOL宏不进行扩展。genksyms命令识别EXPORT_SYMBOL()中的函数名和对应的原型，再根据其原型计算出该函数的版本号。
例如ksyms.c中有一行：
EXPORT_SYMBOL(kmalloc);
kmalloc原型是：
void *kmalloc(size_t, int);
genksyms程序对应的输出为：
#define __ver_kmalloc 93d4cfe6
#define kmalloc _set_ver(kmalloc)
在内核符号表和模块中，kmalloc将变成kmalloc_R93d4cfe6。
在生成完所有的.ver文件后，make将重建include/linux/modversions.h文件，它包含一系列#include指令行嵌入各个.ver文件。在编绎内核本身export-objs中的文件时，make会增加一个＂-DEXPORT_SYMTAB＂编绎标志，它使源文件嵌入modversions.h文件，将EXPORT_SYMBOL宏展开中的函数名字符串进行版本名扩展；同时，它也定义_set_ver()宏为一空操作，使代码中的函数名不受其影响。
在编绎模块时，make会增加＂-include=linux/modversion.h -DMODVERSIONS＂编绎标志，使模块中代码的函数名得到相应版本扩展。
由于生成.ver文件比较费时，make还为每个.ver创建了一个后缀为.stamp时戳文件。在make dep时，如果其.stamp文件比源文件旧才重新生成.ver文件，否则只是更新.stamp文件时戳。另外，在生成.ver和modversions.h文件时，make都会比较新文件和旧文件的内容，保持它们修改时间为最旧。
==========================================
Makefile解读之四： Rules.make的注释
==========================================
[code:1:974578564b]
#
# This file contains rules which are shared between multiple Makefiles.
#
#
# False targets.
#
#
.PHONY: dummy
#
# Special variables which should not be exported
#
# 取消这些变量通过环境向make子进程传递。
unexport EXTRA_AFLAGS # as 的开关
unexport EXTRA_CFLAGS # cc 的开关
unexport EXTRA_LDFLAGS # ld 的开关
unexport EXTRA_ARFLAGS # ar 的开关
unexport SUBDIRS #
unexport SUB_DIRS # 编绎内核需进入的子目录，等于subdir-y
unexport ALL_SUB_DIRS # 所有的子目录
unexport MOD_SUB_DIRS # 编绎模块需进入的子目录
unexport O_TARGET # ld合并的输出对象
unexport ALL_MOBJS # 所有的模块名
unexport obj-y # 编绎成内核的文件集
unexport obj-m # 编绎成模块的文件集
unexport obj-n #
unexport obj- #
unexport export-objs # 需进行版本处理的文件集
unexport subdir-y # 编绎内核所需进入的子目录
unexport subdir-m # 编绎模块所需进入的子目录
unexport subdir-n
unexport subdir-
#
# Get things started.
#
first_rule: sub_dirs
$(MAKE) all_targets
# 在内核编绎子目录中过滤出可以作为模块的子目录。
both-m := $(filter $(mod-subdirs), $(subdir-y))
SUB_DIRS := $(subdir-y)
# 求出总模块子目录
MOD_SUB_DIRS := $(sort $(subdir-m) $(both-m))
# 求出总子目录
ALL_SUB_DIRS := $(sort $(subdir-y) $(subdir-m) $(subdir-n) $(subdir-))
#
# Common rules
#
# 将c文件编绎成汇编文件的规则，$@为目标对象。
%.s: %.c
$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$@) -S $ $@
# 将c文件编绎成目标文件的规则，$ $(dir $@)/.$(notdir $@).flags
# 汇编文件生成目标文件的规则。
%.o: %.s
$(AS) $(AFLAGS) $(EXTRA_CFLAGS) -o $@ $ $@
# 汇编文件生成目标文件的标准规则。
%.o: %.S
$(CC) $(AFLAGS) $(EXTRA_AFLAGS) $(AFLAGS_$@) -c -o $@ $ $(dir $@)/.$(notdir $@).flags
endif # O_TARGET
#
# Rule to compile a set of .o files into one .a file
#
# 将obj-y组合成库L_TARGET的方法。
ifdef L_TARGET
$(L_TARGET): $(obj-y)
rm -f $@
$(AR) $(EXTRA_ARFLAGS) rcs $@ $(obj-y)
@ ( \
echo 'ifeq ($(strip $(subst $(comma),:,$(EXTRA_ARFLAGS)
$(obj-y))),$$(strip $$(subst $$(comma),:,$$(EXTRA_ARFLAGS) $$(obj-y))))' ;
\
echo 'FILES_FLAGS_UP_TO_DATE += $@' ; \
echo 'endif' \
) > $(dir $@)/.$(notdir $@).flags
endif
#
# This make dependencies quickly
#
# wildcard为查找目录中的文件名的宏。
fastdep: dummy
$(TOPDIR)/scripts/mkdep $(wildcard *.[chS] local.h.master) > .depend
ifdef ALL_SUB_DIRS
#
将ALL_SUB_DIRS中的目录名加上前缀_sfdep_作为目标运行子make，并将ALL_SUB_DIRS
通过
# 变量_FASTDEP_ALL_SUB_DIRS传递给子make。
$(MAKE) $(patsubst %,_sfdep_%,$(ALL_SUB_DIRS))
_FASTDEP_ALL_SUB_DIRS="$(ALL_SUB_DIRS)"
endif
ifdef _FASTDEP_ALL_SUB_DIRS
#
与上一段相对应，定义子目录目标，并将目标名还原为目录名，进入该子目录make。
$(patsubst %,_sfdep_%,$(_FASTDEP_ALL_SUB_DIRS)):
$(MAKE) -C $(patsubst _sfdep_%,%,$@) fastdep
endif
#
# A rule to make subdirectories
#
# 下面2段完成内核编绎子目录中的make。
subdir-list = $(sort $(patsubst %,_subdir_%,$(SUB_DIRS)))
sub_dirs: dummy $(subdir-list)
ifdef SUB_DIRS
$(subdir-list) : dummy
$(MAKE) -C $(patsubst _subdir_%,%,$@)
endif
#
# A rule to make modules
#
# 求出有效的模块文件表。
ALL_MOBJS = $(filter-out $(obj-y), $(obj-m))
ifneq "$(strip $(ALL_MOBJS))" ""
# 取主目录TOPDIR到当前目录的路径。
PDWN=$(shell $(CONFIG_SHELL) $(TOPDIR)/scripts/pathdown.sh)
endif
unexport MOD_DIRS
MOD_DIRS := $(MOD_SUB_DIRS) $(MOD_IN_SUB_DIRS)
# 编绎模块时，进入模块子目录的方法。
ifneq "$(strip $(MOD_DIRS))" ""
.PHONY: $(patsubst %,_modsubdir_%,$(MOD_DIRS))
$(patsubst %,_modsubdir_%,$(MOD_DIRS)) : dummy
$(MAKE) -C $(patsubst _modsubdir_%,%,$@) modules
# 安装模块时，进入模块子目录的方法。
.PHONY: $(patsubst %,_modinst_%,$(MOD_DIRS))
$(patsubst %,_modinst_%,$(MOD_DIRS)) : dummy
$(MAKE) -C $(patsubst _modinst_%,%,$@) modules_install
endif
# make modules 的入口。
.PHONY: modules
modules: $(ALL_MOBJS) dummy \
$(patsubst %,_modsubdir_%,$(MOD_DIRS))
.PHONY: _modinst__
# 拷贝模块的过程。
_modinst__: dummy
ifneq "$(strip $(ALL_MOBJS))" ""
mkdir -p $(MODLIB)/kernel/$(PDWN)
cp $(ALL_MOBJS) $(MODLIB)/kernel/$(PDWN)
endif
# make modules_install 的入口，进入子目录安装。
.PHONY: modules_install
modules_install: _modinst__ \
$(patsubst %,_modinst_%,$(MOD_DIRS))
#
# A rule to do nothing
#
dummy:
#
# This is useful for testing
#
script:
$(SCRIPT)
#
# This sets version suffixes on exported symbols
# Separate the object into "normal" objects and "exporting" objects
# Exporting objects are: all objects that define symbol tables
#
ifdef CONFIG_MODULES
# list-multi列出那些由多个文件复合而成的模块；
# 从编绎文件表和模块文件表中过滤出复合模块名。
multi-used := $(filter $(list-multi), $(obj-y) $(obj-m))
# 取复合模块的构成表。
multi-objs := $(foreach m, $(multi-used), $($(basename $(m))-objs))
# 求出需进行编译的总模块表。
active-objs := $(sort $(multi-objs) $(obj-y) $(obj-m))
ifdef CONFIG_MODVERSIONS
ifneq "$(strip $(export-objs))" ""
# 如果有需要进行版本化的文件。
MODINCL = $(TOPDIR)/include/linux/modules
# The -w option (enable warnings) for genksyms will return here in 2.1
# So where has it gone?
#
# Added the SMP separator to stop module accidents between uniprocessor
# and SMP Intel boxes - AC - from bits by Michael Chastain
#
ifdef CONFIG_SMP
genksyms_smp_prefix := -p smp_
else
genksyms_smp_prefix :=
endif
# 从源文件计算版本文件的规则。
$(MODINCL)/%.ver: %.c
@if [ ! -r $(MODINCL)/$*.stamp -o $(MODINCL)/$*.stamp -ot $ $@.tmp'; \
$(CC) $(CFLAGS) -E -D__GENKSYMS__ $ $@.tmp; \
if [ -r $@ ] && cmp -s $@ $@.tmp; then echo $@ is unchanged; rm -f
$@.tmp; \
else echo mv $@.tmp $@; mv -f $@.tmp $@; fi; \
fi; touch $(MODINCL)/$*.stamp
#
将版本处理源文件的扩展名改为.ver，并加上完整的路径名，它们依赖于autoconf.h?br>?br>$(addprefix $(MODINCL)/,$(export-objs:.o=.ver)):
$(TOPDIR)/include/linux/autoconf.h
# updates .ver files but not modversions.h
# 通过fastdep，逐个生成export-objs对应的版本文件。
fastdep: $(addprefix $(MODINCL)/,$(export-objs:.o=.ver))
# updates .ver files and modversions.h like before (is this needed?)
# make dep过程的入口
dep: fastdep update-modverfile
endif # export-objs
# update modversions.h, but only if it would change
# 刷新版本文件的过程。
update-modverfile:
@(echo "#ifndef _LINUX_MODVERSIONS_H";\
echo "#define _LINUX_MODVERSIONS_H"; \
echo "#include "; \
cd $(TOPDIR)/include/linux/modules; \
for f in *.ver; do \
if [ -f $$f ]; then echo "#include "; fi; \
done; \
echo "#endif"; \
) > $(TOPDIR)/include/linux/modversions.h.tmp
@if [ -r $(TOPDIR)/include/linux/modversions.h ] && cmp -s
$(TOPDIR)/include/linux/modversions.h
$(TOPDIR)/include/linux/modversions.h.tmp; then \
echo $(TOPDIR)/include/linux/modversions.h was not updated; \
rm -f $(TOPDIR)/include/linux/modversions.h.tmp; \
else \
echo $(TOPDIR)/include/linux/modversions.h was updated; \
mv -f $(TOPDIR)/include/linux/modversions.h.tmp
$(TOPDIR)/include/linux/modversions.h; \
fi
$(active-objs): $(TOPDIR)/include/linux/modversions.h
else
# 如果没有配置版本化，modversions.h的内容。
$(TOPDIR)/include/linux/modversions.h:
@echo "#include " > $@
endif # CONFIG_MODVERSIONS
ifneq "$(strip $(export-objs))" ""
# 版本化目标文件的编绎方法。
$(export-objs): $(export-objs:.o=.c) $(TOPDIR)/include/linux/modversions.h
$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$@) -DEXPORT_SYMTAB -c $(@:.o=.c)
@ ( \
echo 'ifeq ($(strip $(subst $(comma),:,$(CFLAGS) $(EXTRA_CFLAGS)
$(CFLAGS_$@) -DEXPORT_SYMTAB)),$$(strip $$(subst $$(comma),:,$$(CFLAGS)
$$(EXTRA_CFLAGS) $$(CFLAGS_$@) -DEXPORT_SYMTAB)))' ; \
echo 'FILES_FLAGS_UP_TO_DATE += $@' ; \
echo 'endif' \
) > $(dir $@)/.$(notdir $@).flags
endif
endif # CONFIG_MODULES
#
# include dependency files if they exist
#
# 嵌入源文件之间的依赖关系。
ifneq ($(wildcard .depend),)
include .depend
endif
# 嵌入头文件之间的依赖关系。
ifneq ($(wildcard $(TOPDIR)/.hdepend),)
include $(TOPDIR)/.hdepend
endif
#
# Find files whose flags have changed and force recompilation.
# For safety, this works in the converse direction:
# every file is forced, except those whose flags are positively
up-to-date.
#
# 已经更新过的文件列表。
FILES_FLAGS_UP_TO_DATE :=
# For use in expunging commas from flags, which mung our checking.
comma = ,
# 将当前目录下所有flags文件嵌入。
FILES_FLAGS_EXIST := $(wildcard .*.flags)
ifneq ($(FILES_FLAGS_EXIST),)
include $(FILES_FLAGS_EXIST)
endif
# 将无需更新的文件从总的对象中删除。
FILES_FLAGS_CHANGED := $(strip \
$(filter-out $(FILES_FLAGS_UP_TO_DATE), \
$(O_TARGET) $(L_TARGET) $(active-objs) \
))
# A kludge: .S files don't get flag dependencies (yet),
# because that will involve changing a lot of Makefiles. Also
# suppress object files explicitly listed in $(IGNORE_FLAGS_OBJS).
# This allows handling of assembly files that get translated into
# multiple object files (see arch/ia64/lib/idiv.S, for example).
#
# 将由汇编文件生成的目件文件从FILES_FLAGS_CHANGED删除。
FILES_FLAGS_CHANGED := $(strip \
$(filter-out $(patsubst %.S, %.o, $(wildcard *.S)
$(IGNORE_FLAGS_OBJS)), \
$(FILES_FLAGS_CHANGED)))
# 将FILES_FLAGS_CHANGED设为目标。
ifneq ($(FILES_FLAGS_CHANGED),)
$(FILES_FLAGS_CHANGED): dummy
endif