本文共 8170 字，大约阅读时间需要 27 分钟。

3、自动化变量

在上述的模式规则中，目标和依赖文件都是一系例的文件，那么我们如何书写一个命 令来完成从不同的依赖文件生成相应的目标？因为在每一次的对模式规则的解析时， 都会是不同的目标和依赖文件。

自动化变量就是完成这个功能的。在前面，我们已经对自动化变量有所提涉，相信你看 到这里已对它有一个感性认识了。所谓自动化变量，就是这种变量会把模式中所定义的 一系列的文件自动地挨个取出，直至所有的符合模式的文件都取完了。这种自动化变量 只应出现在规则的命令中。

下面是所有的自动化变量及其说明：

$@ 表示规则中的目标文件集。在模式规则中，如果有多个目标，那么，"$@"就是匹配于 目标中模式定义的集合。

$% 仅当目标是函数库文件中，表示规则中的目标成员名。例如，如果一个目标是"foo.a (bar.o)"，那么，"$%"就是"bar.o"，"$@"就是"foo.a"。如果目标不是函数库文件（Unix 下是[.a]，Windows下是[.lib]），那么，其值为空。

$< 依赖目标中的第一个目标名字。如果依赖目标是以模式（即"%"）定义的，那么"$<"将 是符合模式的一系列的文件集。注意，其是一个一个取出来的。

$? 所有比目标新的依赖目标的集合。以空格分隔。 $^ 所有的依赖目标的集合。以空格分隔。如果在依赖目标中有多个重复的，那个这个变量 会去除重复的依赖目标，只保留一份。

$+ 这个变量很像"$^"，也是所有依赖目标的集合。只是它不去除重复的依赖目标。

$* 这个变量表示目标模式中"%"及其之前的部分。如果目标是"dir/a.foo.b"，并且目标的模 式是"a.%.b"，那么，"$*"的值就是"dir/a.foo"。这个变量对于构造有关联的文件名是比 较有较。如果目标中没有模式的定义，那么"$*"也就不能被推导出，但是，如果目标文 件的后缀是make所识别的，那么"$*"就是除了后缀的那一部分。例如：如果目标 是"foo.c"，因为".c"是make所能识别的后缀名，所以，"$*"的值就是"foo"。这个特性 是GNUmake的，很有可能不兼容于其它版本的make，所以，你应该尽量避免使用"$ *"，除非是在隐含规则或是静态模式中。如果目标中的后缀是 make 所不能识别的，那 么"$*"就是空值。

当你希望只对更新过的依赖文件进行操作时，"$?"在显式规则中很有用，例如，假设 有一个函数库文件叫"lib"，其由其它几个object文件更新。那么把object文件打包的比 较有效率的Makefile规则是：

lib : foo.o bar.o lose.o win.o ar r lib $?

在上述所列出来的自动量变量中。四个变量（$@、$<、$%、$*）在扩展时只会有一个文 件，而另三个的值是一个文件列表。这七个自动化变量还可以取得文件的目录名或是在 当前目录下的符合模式的文件名，只需要搭配上"D"或"F"字样。这是GNUmake中老版 本的特性，在新版本中，我们使用函数"dir"或"notdir"就可以做到了。"D"的含义就是 Directory，就是目录，"F"的含义就是 File，就是文件。

下面是对于上面的七个变量分别加上"D"或是"F"的含义：

$(@D) 表示"$@"的目录部分（不以斜杠作为结尾），如果"$@"值是"dir/foo.o"，那 么"$(@D)"就是"dir"，而如果"$@"中没有包含斜杠的话，其值就是"."（当前目录）。

$(@F) 表 示 "$@" 的 文 件 部 分 ， 如 果 "$@" 值 是 "dir/foo.o" ， 那 么 "$(@F)" 就 是"foo.o"，"$(@F)"相当于函数"$(notdir$@)"。

"$(*D)" "$(*F)" 和上面所述的同理，也是取文件的目录部分和文件部分。对于上面的那个例 子，"$(*D)"返回"dir"，而"$(*F)"返回"foo"

"$(%D)" "$(%F)" 分别表示了函数包文件成员的目录部分和文件部分。这对于形同"archive(member)"形式 的目标中的"member"中包含了不同的目录很有用。

"$(<D)" "$(<F)" 分别表示依赖文件的目录部分和文件部分。

"$(^D)" "$(^F)" 分别表示所有依赖文件的目录部分和文件部分。（无相同的）

"$(+D)" "$(+F)" 分别表示所有依赖文件的目录部分和文件部分。（可以有相同的）

"$(?D)" "$(?F)" 分别表示被更新的依赖文件的目录部分和文件部分。

最后想提醒一下的是，对于"$<"，为了避免产生不必要的麻烦，我们最好给$后面的那 个特定字符都加上圆括号，比如，"$(<)"就要比"$<"要好一些。

还得要注意的是，这些变量只使用在规则的命令中，而且一般都是"显式规则"和"静态 模式规则"（参见前面"书写规则"一章）。其在隐含规则中并没有意义。

4、模式的匹配

一般来说，一个目标的模式有一个有前缀或是后缀的"%"，或是没有前后缀，直接就 是一个"%"。因为"%"代表一个或多个字符，所以在定义好了的模式中，我们把"%"所匹 配的内容叫做"茎"，例如"%.c"所匹配的文件"test.c"中"test"就是"茎"。因为在目标和依 赖目标中同时有"%"时，依赖目标的"茎"会传给目标，当做目标中的"茎"。

当一个模式匹配包含有斜杠（实际也不经常包含）的文件时，那么在进行模式匹配时， 目录部分会首先被移开，然后进行匹配，成功后，再把目录加回去。在进行"茎"的传递 时，我们需要知道这个步骤。例如有一个模式"e%t"，文件"src/eat"匹配于该模式，于 是"src/a"就是其"茎"，如果这个模式定义在依赖目标中，而被依赖于这个模式的目标中 又有个模式"c%r"，那么，目标就是"src/car"。（"茎"被传递）

5、重载内建隐含规则

你可以重载内建的隐含规则（或是定义一个全新的），例如你可以重新构造和内建隐 含规则不同的命令，如：

%.o : %.c $(CC) -c $(CPPFLAGS) $(CFLAGS) -D$(date)

你可以取消内建的隐含规则，只要不在后面写命令就行。如：

%.o : %.s

同样，你也可以重新定义一个全新的隐含规则，其在隐含规则中的位置取决于你在哪 里写下这个规则。朝前的位置就靠前。

六、老式风格的"后缀规则"

后缀规则是一个比较老式的定义隐含规则的方法。后缀规则会被模式规则逐步地取代。 因为模式规则更强更清晰。为了和老版本的Makefile兼容，GNUmake同样兼容于这些 东西。后缀规则有两种方式："双后缀"和"单后缀"。

双后缀规则定义了一对后缀：目标文件的后缀和依赖目标（源文件）的后缀。 如".c.o"相当于"%o:%c"。单后缀规则只定义一个后缀，也就是源文件的后缀。如".c"相 当于"%:%.c"。

后缀规则中所定义的后缀应该是make所认识的，如果一个后缀是make所认识的，那 么这个规则就是单后缀规则，而如果两个连在一起的后缀都被make所认识，那就是双 后缀规则。例如：".c"和".o"都是make所知道。因而，如果你定义了一个规则是".c.o"那 么其就是双后缀规则，意义就是".c"是源文件的后缀，".o"是目标文件的后缀。如下示例：

.c.o:

$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<

后缀规则不允许任何的依赖文件，如果有依赖文件的话，那就不是后缀规则，那些后 缀统统被认为是文件名，如：

.c.o: foo.h $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<

这个例子，就是说，文件".c.o"依赖于文件"foo.h"，而不是我们想要的这样：

%.o: %.c foo.h $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $< 后缀规则中，如果没有命令，那是毫无意义的。因为他也不会移去内建的隐含规则。

而要让make知道一些特定的后缀，我们可以使用伪目标".SUFFIXES"来定义或是删除， 如：

.SUFFIXES: .hack .win

把后缀.hack和.win加入后缀列表中的末尾。

.SUFFIXES: # 删除默认的后缀 .SUFFIXES: .c .o .h # 定义自己的后缀

先清楚默认后缀，后定义自己的后缀列表。

make 的 参 数 "-r" 或 "-no-builtin-rules" 也会 使 用得默认的后 缀 列 表 为 空 。而变 量"SUFFIXE"被用来定义默认的后缀列表，你可以用".SUFFIXES"来改变后缀列表，但 请不要改变变量"SUFFIXE"的值。

七、隐含规则搜索算法

比如我们有一个目标叫T。下面是搜索目标T的规则的算法。请注意，在下面，我们没 有提到后缀规则，原因是，所有的后缀规则在Makefile被载入内存时，会被转换成模 式规则。如果目标是"archive(member)"的函数库文件模式，那么这个算法会被运行两次， 第一次是找目标T，如果没有找到的话，那么进入第二次，第二次会把"member"当作 T 来搜索。

1、把 T 的目录部分分离出来。叫 D，而剩余部分叫 N。（如：如果 T 是"src/foo.o"，那么， D 就是"src/"，N 就是"foo.o"）

2、创建所有匹配于 T 或是 N 的模式规则列表。

3、如果在模式规则列表中有匹配所有文件的模式，如"%"，那么从列表中移除其它的 模式。

4、移除列表中没有命令的规则。

5、对于第一个在列表中的模式规则： 1）推导其"茎"S，S 应该是 T 或是 N 匹配于模式中"%"非空的部分。 2）计算依赖文件。把依赖文件中的"%"都替换成"茎"S。如果目标模式中没有包含斜框字 符，而把D加在第一个依赖文件的开头。 3）测试是否所有的依赖文件都存在或是理当存在。（如果有一个文件被定义成另外一 个规则的目标文件，或者是一个显式规则的依赖文件，那么这个文件就叫"理当存在"） 4）如果所有的依赖文件存在或是理当存在，或是就没有依赖文件。那么这条规则将被 采用，退出该算法。

6、如果经过第 5 步，没有模式规则被找到，那么就做更进一步的搜索。对于存在于列表 中的第一个模式规则： 1）如果规则是终止规则，那就忽略它，继续下一条模式规则。 2）计算依赖文件。（同第 5 步） 3）测试所有的依赖文件是否存在或是理当存在。 4）对于不存在的依赖文件，递归调用这个算法查找他是否可以被隐含规则找到。 5）如果所有的依赖文件存在或是理当存在，或是就根本没有依赖文件。那么这条规则 被采用，退出该算法。

7 、如果 没 有 隐 含规则可以 使 用，查看 ".DEFAULT" 规则，如果有， 采 用， 把".DEFAULT"的命令给T使用。

一旦规则被找到，就会执行其相当的命令，而此时，我们的自动化变量的值才会生成。

使用make更新函数库文件

———————————

函数库文件也就是对Object文件（程序编译的中间文件）的打包文件。在Unix下，一 般是由命令"ar"来完成打包工作。

一、函数库文件的成员

一个函数库文件由多个文件组成。你可以以如下格式指定函数库文件及其组成：

archive(member)

这个不是一个命令，而一个目标和依赖的定义。一般来说，这种用法基本上就是为 了"ar"命令来服务的。如：

foolib(hack.o) : hack.o ar cr foolib hack.o

如果要指定多个member，那就以空格分开，如：

foolib(hack.o kludge.o)

其等价于：

foolib(hack.o) foolib(kludge.o) 你还可以使用Shell的文件通配符来定义，如：

foolib(*.o)

二、函数库成员的隐含规则

当make搜索一个目标的隐含规则时，一个特殊的特性是，如果这个目标是"a(m)"形式 的，其会把目标变成"(m)"。于是，如果我们的成员是"%.o"的模式定义，并且如果我们 使用"makefoo.a(bar.o)"的形式调用Makefile时，隐含规则会去找"bar.o"的规则，如果 没有定义bar.o的规则，那么内建隐含规则生效，make会去找bar.c文件来生成bar.o， 如果找得到的话，make执行的命令大致如下：

cc -c bar.c -o bar.o ar r foo.a bar.o rm -f bar.o

还有一个变量要注意的是"$%"，这是专属函数库文件的自动化变量，有关其说明请参 见"自动化变量"一节。

三、函数库文件的后缀规则

你可以使用"后缀规则"和"隐含规则"来生成函数库打包文件，如：

.c.a: $(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $*.o $(AR) r $@ $*.o $(RM) $*.o

其等效于：

(%.o) : %.c $(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $*.o $(AR) r $@ $*.o $(RM) $*.o

四、注意事项

在进行函数库打包文件生成时，请小心使用make的并行机制（"-j"参数）。如果多个ar 命令在同一时间运行在同一个函数库打包文件上，就很有可以损坏这个函数库文件。所 以，在make未来的版本中，应该提供一种机制来避免并行操作发生在函数打包文件上。 但就目前而言，你还是应该不要尽量不要使用"-j"参数。 后序 ——

终于到写结束语的时候了，以上基本上就是GNUmake的Makefile的所有细节了。其它 的产商的make基本上也就是这样的，无论什么样的make，都是以文件的依赖性为基 础的，其基本是都是遵循一个标准的。这篇文档中80%的技术细节都适用于任何的 make，我猜测"函数"那一章的内容可能不是其它 make 所支持的，而隐含规则方面，我 想不同的make会有不同的实现，我没有精力来查看GNU的make和VC的nmake、 BCB 的 make，或是别的 UNIX 下的 make 有些什么样的差别，一是时间精力不够，二 是因为我基本上都是在Unix下使用make，以前在SCOUnix和IBM的AIX，现在在 Linux、Solaris、HP-UX、AIX 和 Alpha 下使用，Linux 和 Solaris 下更多一点。不过，我可 以肯定的是，在Unix下的make，无论是哪种平台，几乎都使用了RichardStallman开 发的make和cc/gcc的编译器，而且，基本上都是GNU的make（公司里所有的UNIX 机器上都被装上了GNU的东西，所以，使用GNU的程序也就多了一些）。GNU的东 西还是很不错的，特别是使用得深了以后，越来越觉得GNU的软件的强大，也越来越 觉得GNU的在操作系统中（主要是Unix，甚至Windows）"杀伤力"。

对于上述所有的make的细节，我们不但可以利用make这个工具来编译我们的程序， 还可以利用make来完成其它的工作，因为规则中的命令可以是任何Shell之下的命令， 所以，在Unix下，你不一定只是使用程序语言的编译器，你还可以在Makefile中书写 其它的命令，如：tar、awk、mail、sed、cvs、compress、、rm、yacc、rpm、ftp……等等，等等，                                                   ls 来完成诸如"程序打包"、"程序备份"、"制作程序安装包"、"提交代码"、"使用程序模 板" 、"合并文件"等等五花八门的功能，文件操作，文件管理，编程开发设计，或是其 它一些异想天开的东西。比如，以前在书写银行交易程序时，由于银行的交易程序基本 一样，就见到有人书写了一些交易的通用程序模板，在该模板中把一些网络通讯、数据 库操作的、业务操作共性的东西写在一个文件中，在这些文件中用些诸如"@@@N、 ###N"奇怪字串标注一些位置，然后书写交易时，只需按照一种特定的规则书写特定 的处理，最后在make时，使用awk和sed，把模板中的"@@@N、###N"等字串替代成 特定的程序，形成C文件，然后再编译。这个动作很像数据库的"扩展C"语言（即在C 语言中用"EXEC　SQL"的样子执行SQL语句，在用cc/gcc编译之前，需要使用"扩展 C"的翻译程序，如 cpre，把其翻译成标准 C）。如果你在使用 make 时有一些更为绝妙 的方法，请记得告诉我啊。

回头看看整篇文档，不觉记起几年前刚刚开始在Unix下做开发的时候，有人问我会不 会写Makefile时，我两眼发直，根本不知道在说什么。一开始看到别人在vi中写完程 序后输入"!make"时，还以为是vi的功能，后来才知道有一个Makefile在作怪，于是上 网查啊查，那时又不愿意看英文，发现就根本没有中文的文档介绍Makefile，只得看 别人写的Makefile，自己瞎碰瞎搞才积累了一点知识，但在很多地方完全是知其然不 知所以然。后来开始从事UNIX下产品软件的开发，看到一个400人年，近200万行代 码的大工程，发现要编译这样一个庞然大物，如果没有Makefile，那会是多么恐怖的 一样事啊。于是横下心来，狠命地读了一堆英文文档，才觉得对其掌握了。但发现目前 网上对Makefile介绍的文章还是少得那么的可怜，所以想写这样一篇文章，共享给大 家，希望能对各位有所帮助。

现在我终于写完了，看了看文件的创建时间，这篇技术文档也写了两个多月了。发现， 自己知道是一回事，要写下来，跟别人讲述又是另外一回事，而且，现在越来越没有 时间专研技术细节，所以在写作时，发现在阐述一些细节问题时很难做到严谨和精练， 而且对先讲什么后讲什么不是很清楚，所以，还是参考了一些国外站点上的资料和题 纲，以及一些技术书籍的语言风格，才得以完成。整篇文档的提纲是基于GNU的 Makefile 技术手册的提纲来书写的，并结合了自己的工作经验，以及自己的学习历程。 因为从来没有写过这么长，这么细的文档，所以一定会有很多地方存在表达问题，语 言歧义或是错误。因些，我迫切地得等待各位给我指证和建议，以及任何的反馈。

最后，还是利用这个后序，介绍一下自己。我目前从事于所有Unix平台下的软件研发， 主要是做分布式计算/网格计算方面的系统产品软件，并且我对于下一代的计算机革命 ——网格计算非常地感兴趣，对于分布式计算、P2P、WebService、J2EE技术方向也很感 兴趣，同时，对于项目实施、团队管理、项目管理也小有心得，希望同样和我战斗在“ 技术和管理并重”的阵线上的年轻一代，能够和我多多地交流。我的 MSN是： （常用），QQ 是：753640（不常用）。（注：请勿给我 MSN 的邮 箱发信，由于hotmail的垃圾邮件导致我拒收这个邮箱的所有来信）

我欢迎任何形式的交流，无论是讨论技术还是管理，或是其它海阔天空的东西。除了政 治和娱乐新闻我不关心，其它只要积极向上的东西我都欢迎！

最最后，我还想介绍一下make程序的设计开发者。

首当其冲的是：RichardStallman

开源软件的领袖和先驱，从来没有领过一天工资，从来没有使用过Windows操作系统。 对于他的事迹和他的软件以及他的思想，我无需说过多的话，相信大家对这个人并不 比我陌生，这是他的主页： 。

第二位是：RolandMcGrath

个人主页是： ，下面是他的一些事迹：

1）合作编写了并维护 GNU make。

2）和 Thomas Bushnell 一同编写了 GNU Hurd。 3）编写并维护着 GNU C library。

4）合作编写并维护着部分的 GNU Emacs。

在此，向这两位开源项目的斗士致以最真切的敬意。

（全文完）

转载地址：http://ehbhb.baihongyu.com/