跟我一起写 Makefile

 search.o : search.c defs.h buffer.h 
 cc -c search.c 
 files.o : files.c defs.h buffer.h command.h 
 cc -c files.c 
 utils.o : utils.c defs.h 
 cc -c utils.c 
 clean : 
 rm edit $(objects) 


于是如果有新的 .o 文件加入，我们只需简单地修改一下 objects 变量就可以了。 

关于变量更多的话题，我会在后续给你一一道来。 


五、让make自动推导 

GNU的make很强大，它可以自动推导文件以及文件依赖关系后面的命令，于是我们就没必要去在每一个[.o]文件后都写上类似的命令，因为，我们的make会自动识别，并自己推导命令。 

只要make看到一个[.o]文件，它就会自动的把[.c]文件加在依赖关系中，如果make找到一个whatever.o，那么whatever.c，就会是whatever.o的依赖文件。并且 cc -c whatever.c 也会被推导出来，于是，我们的makefile再也不用写得这么复杂。我们的是新的makefile又出炉了。 


 objects = main.o kbd.o command.o display.o \ 
 insert.o search.o files.o utils.o 

 edit : $(objects) 
 cc -o edit $(objects) 

 main.o : defs.h 
 kbd.o : defs.h command.h 
 command.o : defs.h command.h 
 display.o : defs.h buffer.h 
 insert.o : defs.h buffer.h 
 search.o : defs.h buffer.h 
 files.o : defs.h buffer.h command.h 
 utils.o : defs.h 

 .PHONY : clean 
 clean : 
 rm edit $(objects) 

这种方法，也就是make的“隐晦规则”。上面文件内容中，“.PHONY”表示，clean是个伪目标文件。 

关于更为详细的“隐晦规则”和“伪目标文件”，我会在后续给你一一道来。 


六、另类风格的makefile 

即然我们的make可以自动推导命令，那么我看到那堆[.o]和[.h]的依赖就有点不爽，那么多的重复的[.h]，能不能把其收拢起来，好吧，没有问题，这个对于make来说很容易，谁叫它提供了自动推导命令和文件的功能呢？来看看最新风格的makefile吧。 

 objects = main.o kbd.o command.o display.o \ 
 insert.o search.o files.o utils.o 

 edit : $(objects) 
 cc -o edit $(objects) 

 $(objects) : defs.h 
 kbd.o command.o files.o : command.h 
 display.o insert.o search.o files.o : buffer.h 

 .PHONY : clean 
 clean : 
 rm edit $(objects) 

这种风格，让我们的makefile变得很简单，但我们的文件依赖关系就显得有点凌乱了。鱼和熊掌不可兼得。还看你的喜好了。我是不喜欢这种风格的，一是文件的依赖关系看不清楚，二是如果文件一多，要加入几个新的.o文件，那就理不清楚了。 


七、清空目标文件的规则 

每个Makefile中都应该写一个清空目标文件（.o和执行文件）的规则，这不仅便于重编译，也很利于保持文件的清洁。这是一个“修养”（呵呵，还记得我的《编程修养》吗）。一般的风格都是： 

 clean: 
 rm edit $(objects) 

更为稳健的做法是： 

 .PHONY : clean 
 clean : 
 -rm edit $(objects) 

前面说过，.PHONY意思表示clean是一个“伪目标”，。而在rm命令前面加了一个小减号的意思就是，也许某些文件出现问题，但不要管，继续做后面的事。当然，clean的规则不要放在文件的开头，不然，这就会变成make的默认目标，相信谁也不愿意这样。不成文的规矩是——“clean从来都是放在文件的最后”。 


上面就是一个makefile的概貌，也是makefile的基础，下面还有很多makefile的相关细节，准备好了吗？准备好了就来。

书写规则 
———— 

规则包含两个部分，一个是依赖关系，一个是生成目标的方法。 

在Makefile中，规则的顺序是很重要的，因为，Makefile中只应该有一个最终目标，其它的目标都是被这个目标所连带出来的，所以一定要让make知道你的最终目标是什么。一般来说，定义在Makefile中的目标可能会有很多，但是第一条规则中的目标将被确立为最终的目标。如果第一条规则中的目标有很多个，那么，第一个目标会成为最终的目标。make所完成的也就是这个目标。 

好了，还是让我们来看一看如何书写规则。 


一、规则举例 

 foo.o : foo.c defs.h # foo模块 
 cc -c -g foo.c 

看到这个例子，各位应该不是很陌生了，前面也已说过，foo.o是我们的目标，foo.c和defs.h是目标所依赖的源文件，而只有一个命令“cc -c -g foo.c”（以Tab键开头）。这个规则告诉我们两件事： 

 1、文件的依赖关系，foo.o依赖于foo.c和defs.h的文件，如果foo.c和defs.h的文件日期要比foo.o文件日期要新，或是foo.o不存在，那么依赖关系发生。 
 2、如果生成（或更新）foo.o文件。也就是那个cc命令，其说明了，如何生成foo.o这个文件。（当然foo.c文件include了defs.h文件） 


二、规则的语法 

 targets : prerequisites 
 command 
 ... 

 或是这样： 

 targets : prerequisites ; command 
 command 
 ... 

targets是文件名，以空格分开，可以使用通配符。一般来说，我们的目标基本上是一个文件，但也有可能是多个文件。 

command是命令行，如果其不与“target:prerequisites”在一行，那么，必须以[Tab键]开头，如果和prerequisites在一行，那么可以用分号做为分隔。（见上） 

prerequisites也就是目标所依赖的文件（或依赖目标）。如果其中的某个文件要比目标文件要新，那么，目标就被认为是“过时的”，被认为是需要重生成的。这个在前面已经讲过了。 

如果命令太长，你可以使用反斜框（‘\’）作为换行符。make对一行上有多少个字符没有限制。规则告诉make两件事，文件的依赖关系和如何成成目标文件。 

一般来说，make会以UNIX的标准Shell，也就是/bin/sh来执行命令。 


三、在规则中使用通配符 

如果我们想定义一系列比较类似的文件，我们很自然地就想起使用通配符。make支持三各通配符：“*”，“?”和“[...]”。这是和Unix的B-Shell是相同的。 

波浪号（“~”）字符在文件名中也有比较特殊的用途。如果是“~/test”，这就表示当前用户的$HOME目录下的test目录。而“~hchen/test”则表示用户hchen的宿主目录下的test目录。（这些都是Unix下的小知识了，make也支持）而在Windows或是MS-DOS下，用户没有宿主目录，那么波浪号所指的目录则根据环境变量“HOME”而定。 

通配符代替了你一系列的文件，如“*.c”表示所以后缀为c的文件。一个需要我们注意的是，如果我们的文件名中有通配符，如：“*”，那么可以用转义字符“\”，如“\*”来表示真实的“*”字符，而不是任意长度的字符串。 

好吧，还是先来看几个例子吧： 

 clean: 
 rm -f *.o 

 上面这个例子我不不多说了，这是操作系统Shell所支持的通配符。这是在命令中的通配符。 

 print: *.c 
 lpr -p $? 
 touch print 

 上面这个例子说明了通配符也可以在我们的规则中，目标print依赖于所有的[.c]文件。其中的“$?”是一个自动化变量，我会在后面给你讲述。 

 objects = *.o 

 上面这个例子，表示了，通符同样可以用在变量中。并不是说[*.o]会展开，不！objects的值就是“*.o”。Makefile中的变量其实就是C/C++中的宏。如果你要让通配符在变量中展开，也就是让objects的值是所有[.o]的文件名的集合，那么，你可以这样： 

 objects := $(wildcard *.o) 

这种用法由关键字“wildcard”指出，关于Makefile的关键字，我们将在后面讨论。 


六、多目标 

Makefile的规则中的目标可以不止一个，其支持多目标，有可能我们的多个目标同时依赖于一个文件，并且其生成的命令大体类似。于是我们就能把其合并起来。当然，多个目标的生成规则的执行命令是同一个，这可能会可我们带来麻烦，不过好在我们的可以使用一个自动化变量“$@”（关于自动化变量，将在后面讲述），这个变量表示着目前规则中所有的目标的集合，这样说可能很抽象，还是看一个例子吧。 

 bigoutput littleoutput : text.g 
 generate text.g -$(subst output,,$@) >; $@ 

 上述规则等价于： 

 bigoutput : text.g 
 generate text.g -big >; bigoutput 
 littleoutput : text.g 
 generate text.g -little >; littleoutput 

 其中，-$(subst output,,$@)中的“$”表示执行一个Makefile的函数，函数名为subst，后面的为参数。关于函数，将在后面讲述。这里的这个函数是截取字符串的意思，“$@”表示目标的集合，就像一个数组，“$@”依次取出目标，并执于命令。 


七、静态模式 

静态模式可以更加容易地定义多目标的规则，可以让我们的规则变得更加的有弹性和灵活。我们还是先来看一下语法： 

 <targets ...>;: <target-pattern>;: <prereq-patterns ...>; 
 <commands>; 
 ... 


 targets定义了一系列的目标文件，可以有通配符。是目标的一个集合。 

 target-parrtern是指明了targets的模式，也就是的目标集模式。 

 prereq-parrterns是目标的依赖模式，它对target-parrtern形成的模式再进行一次依赖目标的定义。 

这样描述这三个东西，可能还是没有说清楚，还是举个例子来说明一下吧。如果我们的<target-parrtern>;定义成“%.o”，意思是我们的<target>;集合中都是以“.o”结尾的，而如果我们的<prereq-parrterns>;定义成“%.c”，意思是对<target-parrtern>;所形成的目标集进行二次定义，其计算方法是，取<target-parrtern>;模式中的“%”（也就是去掉了[.o]这个结尾），并为其加上[.c]这个结尾，形成的新集合。 

所以，我们的“目标模式”或是“依赖模式”中都应该有“%”这个字符，如果你的文件名中有“%”那么你可以使用反斜杠“\”进行转义，来标明真实的“%”字符。 

看一个例子： 

 objects = foo.o bar.o 

 all: $(objects) 

 $(objects): %.o: %.c 
 $(CC) -c $(CFLAGS) $< -o $@ 


上面的例子中，指明了我们的目标从$object中获取，“%.o”表明要所有以“.o”结尾的目标，也就是“foo.o bar.o”，也就是变量$object集合的模式，而依赖模式“%.c”则取模式“%.o”的“%”，也就是“foo bar”，并为其加下“.c”的后缀，于是，我们的依赖目标就是“foo.c bar.c”。而命令中的“$<”和“$@”则是自动化变量，“$<”表示所有的依赖目标集（也就是“foo.c bar.c”），“$@”表示目标集（也就是“foo.o bar.o”）。于是，上面的规则展开后等价于下面的规则： 

 foo.o : foo.c 
 $(CC) -c $(CFLAGS) foo.c -o foo.o 
 bar.o : bar.c 
 $(CC) -c $(CFLAGS) bar.c -o bar.o 

试想，如果我们的“%.o”有几百个，那种我们只要用这种很简单的“静态模式规则”就可以写完一堆规则，实在是太有效率了。“静态模式规则”的用法很灵活，如果用得好，那会一个很强大的功能。再看一个例子： 


 files = foo.elc bar.o lose.o 

 $(filter %.o,$(files)): %.o: %.c 
 $(CC) -c $(CFLAGS) $< -o $@ 
 $(filter %.elc,$(files)): %.elc: %.el 
 emacs -f batch-byte-compile $< 


$(filter %.o,$(files))表示调用Makefile的filter函数，过滤“$filter”集，只要其中模式为“%.o”的内容。其的它内容，我就不用多说了吧。这个例字展示了Makefile中更大的弹性。 


八、自动生成依赖性 

在Makefile中，我们的依赖关系可能会需要包含一系列的头文件，比如，如果我们的main.c中有一句“#include "defs.h"”，那么我们的依赖关系应该是： 


使用变量 
———— 

在Makefile中的定义的变量，就像是C/C++语言中的宏一样，他代表了一个文本字串，在Makefile中执行的时候其会自动原模原样地展开在所使用的地方。其与C/C++所不同的是，你可以在Makefile中改变其值。在Makefile中，变量可以使用在“目标”，“依赖目标”，“命令”或是Makefile的其它部分中。 

变量的命名字可以包含字符、数字，下划线（可以是数字开头），但不应该含有“:”、“#”、“=”或是空字符（空格、回车等）。变量是大小写敏感的，“foo”、“Foo”和“FOO”是三个不同的变量名。传统的Makefile的变量名是全大写的命名方式，但我推荐使用大小写搭配的变量名，如：MakeFlags。这样可以避免和系统的变量冲突，而发生意外的事情。 

有一些变量是很奇怪字串，如“$<”、“$@”等，这些是自动化变量，我会在后面介绍。 

一、变量的基础 

变量在声明时需要给予初值，而在使用时，需要给在变量名前加上“$”符号，但最好用小括号“（）”或是大括号“{}”把变量给包括起来。如果你要使用真实的“$”字符，那么你需要用“$$”来表示。 

变量可以使用在许多地方，如规则中的“目标”、“依赖”、“命令”以及新的变量中。先看一个例子： 

 objects = program.o foo.o utils.o 
 program : $(objects) 
 cc -o program $(objects) 

 $(objects) : defs.h 

变量会在使用它的地方精确地展开，就像C/C++中的宏一样，例如： 

 foo = c 
 prog.o : prog.$(foo) 
 $(foo)$(foo) -$(foo) prog.$(foo) 

展开后得到： 

 prog.o : prog.c 
 cc -c prog.c 

当然，千万不要在你的Makefile中这样干，这里只是举个例子来表明Makefile中的变量在使用处展开的真实样子。可见其就是一个“替代”的原理。 

另外，给变量加上括号完全是为了更加安全地使用这个变量，在上面的例子中，如果你不想给变量加上括号，那也可以，但我还是强烈建议你给变量加上括号。 


二、变量中的变量 

在定义变量的值时，我们可以使用其它变量来构造变量的值，在Makefile中有两种方式来在用变量定义变量的值。 

先看第一种方式，也就是简单的使用“=”号，在“=”左侧是变量，右侧是变量的值，右侧变量的值可以定义在文件的任何一处，也就是说，右侧中的变量不一定非要是已定义好的值，其也可以使用后面定义的值。如： 

 foo = $(bar) 
 bar = $(ugh) 
 ugh = Huh? 

 all: 
 echo $(foo) 

我们执行“make all”将会打出变量$(foo)的值是“Huh?”（ $(foo)的值是$(bar)，$(bar)的值是$(ugh)，$(ugh)的值是“Huh?”）可见，变量是可以使用后面的变量来定义的。 

这个功能有好的地方，也有不好的地方，好的地方是，我们可以把变量的真实值推到后面来定义，如： 

 CFLAGS = $(include_dirs) -O 
 include_dirs = -Ifoo -Ibar 

当“CFLAGS”在命令中被展开时，会是“-Ifoo -Ibar -O”。但这种形式也有不好的地方，那就是递归定义，如： 

 CFLAGS = $(CFLAGS) -O 

 或： 

 A = $(B) 
 B = $(A) 

这会让make陷入无限的变量展开过程中去，当然，我们的make是有能力检测这样的定义，并会报错。还有就是如果在变量中使用函数，那么，这种方式会让我们的make运行时非常慢，更糟糕的是，他会使用得两个make的函数“wildcard”和“shell”发生不可预知的错误。因为你不会知道这两个函数会被调用多少次。 

为了避免上面的这种方法，我们可以使用make中的另一种用变量来定义变量的方法。这种方法使用的是“:=”操作符，如： 

 x := foo 
 y := $(x) bar 
 x := later 

其等价于： 

 y := foo bar 
 x := later 

值得一提的是，这种方法，前面的变量不能使用后面的变量，只能使用前面已定义好了的变量。如果是这样： 

 y := $(x) bar 


 x := foo 

那么，y的值是“bar”，而不是“foo bar”。 

上面都是一些比较简单的变量使用了，让我们来看一个复杂的例子，其中包括了make的函数、条件表达式和一个系统变量“MAKELEVEL”的使用： 

 ifeq (0,${MAKELEVEL}) 
 cur-dir := $(shell pwd) 
 whoami := $(shell whoami) 
 host-type := $(shell arch) 
 MAKE := ${MAKE} host-type=${host-type} whoami=${whoami} 
 endif 

关于条件表达式和函数，我们在后面再说，对于系统变量“MAKELEVEL”，其意思是，如果我们的make有一个嵌套执行的动作（参见前面的“嵌套使用make”），那么，这个变量会记录了我们的当前Makefile的调用层数。 

下面再介绍两个定义变量时我们需要知道的，请先看一个例子，如果我们要定义一个变量，其值是一个空格，那么我们可以这样来： 

 nullstring := 
 space := $(nullstring) # end of the line 

nullstring是一个Empty变量，其中什么也没有，而我们的space的值是一个空格。因为在操作符的右边是很难描述一个空格的，这里采用的技术很管用，先用一个Empty变量来标明变量的值开始了，而后面采用“#”注释符来表示变量定义的终止，这样，我们可以定义出其值是一个空格的变量。请注意这里关于“#”的使用，注释符“#”的这种特性值得我们注意，如果我们这样定义一个变量： 

 dir := /foo/bar # directory to put the frobs in 

dir这个变量的值是“/foo/bar”，后面还跟了4个空格，如果我们这样使用这样变量来指定别的目录——“$(dir)/file”那么就完蛋了。 

还有一个比较有用的操作符是“?=”，先看示例： 

 FOO ?= bar 

其含义是，如果FOO没有被定义过，那么变量FOO的值就是“bar”，如果FOO先前被定义过，那么这条语将什么也不做，其等价于： 

 ifeq ($(origin FOO), undefined) 
 FOO = bar 
 endif 


三、变量高级用法 

这里介绍两种变量的高级使用方法，第一种是变量值的替换。 

我们可以替换变量中的共有的部分，其格式是“$(var:a=b)”或是“${var:a=b}”，其意思是，把变量“var”中所有以“a”字串“结尾”的“a”替换成“b”字串。这里的“结尾”意思是“空格”或是“结束符”。 

还是看一个示例吧： 

 foo := a.o b.o c.o 
 bar := $(foo:.o=.c) 

这个示例中，我们先定义了一个“$(foo)”变量，而第二行的意思是把“$(foo)”中所有以“.o”字串“结尾”全部替换成“.c”，所以我们的“$(bar)”的值就是“a.c b.c c.c”。 

另外一种变量替换的技术是以“静态模式”（参见前面章节）定义的，如： 

 foo := a.o b.o c.o 
 bar := $(foo:%.o=%.c) 

这依赖于被替换字串中的有相同的模式，模式中必须包含一个“%”字符，这个例子同样让$(bar)变量的值为“a.c b.c c.c”。 

第二种高级用法是——“把变量的值再当成变量”。先看一个例子： 

 x = y 
 y = z 
 a := $($(x)) 

在这个例子中，$(x)的值是“y”，所以$($(x))就是$(y)，于是$(a)的值就是“z”。（注意，是“x=y”，而不是“x=$(y)”） 

我们还可以使用更多的层次： 

 x = y 
 y = z 
 z = u 
 a := $($($(x))) 

这里的$(a)的值是“u”，相关的推导留给读者自己去做吧。 

让我们再复杂一点，使用上“在变量定义中使用变量”的第一个方式，来看一个例子： 

 x = $(y) 
 y = z 
 z = Hello 
 a := $($(x)) 

这里的$($(x))被替换成了$($(y))，因为$(y)值是“z”，所以，最终结果是：a:=$(z)，也就是“Hello”。 

再复杂一点，我们再加上函数： 

 x = variable1 
 variable2 := Hello 
 y = $(subst 1,2,$(x)) 
 z = y 
 a := $($($(z))) 

这个例子中，“$($($(z)))”扩展为“$($(y))”，而其再次被扩展为“$($(subst 1,2,$(x)))”。$(x)的值是“variable1”，subst函数把“variable1”中的所有“1”字串替换成“2”字串，于是，“variable1”变成“variable2”，再取其值，所以，最终，$(a)的值就是$(variable2)的值——“Hello”。（喔，好不容易） 


六、多行变量 
 
还有一种设置变量值的方法是使用define关键字。使用define关键字设置变量的值可以有换行，这有利于定义一系列的命令（前面我们讲过“命令包”的技术就是利用这个关键字）。 

define指示符后面跟的是变量的名字，而重起一行定义变量的值，定义是以endef关键字结束。其工作方式和“=”操作符一样。变量的值可以包含函数、命令、文字，或是其它变量。因为命令需要以[Tab]键开头，所以如果你用define定义的命令变量中没有以[Tab]键开头，那么make就不会把其认为是命令。 

下面的这个示例展示了define的用法： 

 define two-lines 
 echo foo 
 echo $(bar) 
 endef 


七、环境变量 

make运行时的系统环境变量可以在make开始运行时被载入到Makefile文件中，但是如果Makefile中已定义了这个变量，或是这个变量由make命令行带入，那么系统的环境变量的值将被覆盖。（如果make指定了“-e”参数，那么，系统环境变量将覆盖Makefile中定义的变量） 

因此，如果我们在环境变量中设置了“CFLAGS”环境变量，那么我们就可以在所有的Makefile中使用这个变量了。这对于我们使用统一的编译参数有比较大的好处。如果Makefile中定义了CFLAGS，那么则会使用Makefile中的这个变量，如果没有定义则使用系统环境变量的值，一个共性和个性的统一，很像“全局变量”和“局部变量”的特性。 

当make嵌套调用时（参见前面的“嵌套调用”章节），上层Makefile中定义的变量会以系统环境变量的方式传递到下层的Makefile中。当然，默认情况下，只有通过命令行设置的变量会被传递。而定义在文件中的变量，如果要向下层Makefile传递，则需要使用exprot关键字来声明。（参见前面章节） 

当然，我并不推荐把许多的变量都定义在系统环境中，这样，在我们执行不用的Makefile时，拥有的是同一套系统变量，这可能会带来更多的麻烦。 


八、目标变量 

前面我们所讲的在Makefile中定义的变量都是“全局变量”，在整个文件，我们都可以访问这些变量。当然，“自动化变量”除外，如“$<”等这种类量的自动化变量就属于“规则型变量”，这种变量的值依赖于规则的目标和依赖目标的定义。 

当然，我样同样可以为某个目标设置局部变量，这种变量被称为“Target-specific Variable”，它可以和“全局变量”同名，因为它的作用范围只在这条规则以及连带规则中，所以其值也只在作用范围内有效。而不会影响规则链以外的全局变量的值。 

其语法是： 

 <target ...>; : <variable-assignment>; 

 <target ...>; : overide <variable-assignment>; 

<variable-assignment>;可以是前面讲过的各种赋值表达式，如“=”、“:=”、“+=”或是“？=”。第二个语法是针对于make命令行带入的变量，或是系统环境变量。 

这个特性非常的有用，当我们设置了这样一个变量，这个变量会作用到由这个目标所引发的所有的规则中去。如： 

 prog : CFLAGS = -g 
 prog : prog.o foo.o bar.o 
 $(CC) $(CFLAGS) prog.o foo.o bar.o 

 prog.o : prog.c 
 $(CC) $(CFLAGS) prog.c 

 foo.o : foo.c 
 $(CC) $(CFLAGS) foo.c 

 bar.o : bar.c 
 $(CC) $(CFLAGS) bar.c 
 
在这个示例中，不管全局的$(CFLAGS)的值是什么，在prog目标，以及其所引发的所有规则中（prog.o foo.o bar.o的规则），$(CFLAGS)的值都是“-g” 


九、模式变量 

在GNU的make中，还支持模式变量（Pattern-specific Variable），通过上面的目标变量中，我们知道，变量可以定义在某个目标上。模式变量的好处就是，我们可以给定一种“模式”，可以把变量定义在符合这种模式的所有目标上。 

我们知道，make的“模式”一般是至少含有一个“%”的，所以，我们可以以如下方式给所有以[.o]结尾的目标定义目标变量： 


使用函数 
———— 

在Makefile中可以使用函数来处理变量，从而让我们的命令或是规则更为的灵活和具有智能。make所支持的函数也不算很多，不过已经足够我们的操作了。函数调用后，函数的返回值可以当做变量来使用。 


一、函数的调用语法 

函数调用，很像变量的使用，也是以“$”来标识的，其语法如下： 

 $(<function>; <arguments>;) 

或是 

 ${<function>; <arguments>;} 

这里，<function>;就是函数名，make支持的函数不多。<arguments>;是函数的参数，参数间以逗号“,”分隔，而函数名和参数之间以“空格”分隔。函数调用以“$”开头，以圆括号或花括号把函数名和参数括起。感觉很像一个变量，是不是？函数中的参数可以使用变量，为了风格的统一，函数和变量的括号最好一样，如使用“$(subst a,b,$(x))”这样的形式，而不是“$(subst a,b,${x})”的形式。因为统一会更清楚，也会减少一些不必要的麻烦。 

还是来看一个示例： 

 comma:= , 
 empty:= 
 space:= $(empty) $(empty) 
 foo:= a b c 
 bar:= $(subst $(space),$(comma),$(foo)) 

在这个示例中，$(comma)的值是一个逗号。$(space)使用了$(empty)定义了一个空格，$(foo)的值是“a b c”，$(bar)的定义用，调用了函数“subst”，这是一个替换函数，这个函数有三个参数，第一个参数是被替换字串，第二个参数是替换字串，第三个参数是替换操作作用的字串。这个函数也就是把$(foo)中的空格替换成逗号，所以$(bar)的值是“a,b,c”。 


二、字符串处理函数 

$(subst <from>;,<to>;,<text>;) 

 名称：字符串替换函数——subst。 
 功能：把字串<text>;中的<from>;字符串替换成<to>;。 
 返回：函数返回被替换过后的字符串。 

 示例： 
 
 $(subst ee,EE,feet on the street)， 
 
 把“feet on the street”中的“ee”替换成“EE”，返回结果是“fEEt on the strEEt”。 


$(patsubst <pattern>;,<replacement>;,<text>;) 

 名称：模式字符串替换函数——patsubst。 
 功能：查找<text>;中的单词（单词以“空格”、“Tab”或“回车”“换行”分隔）是否符合模式<pattern>;，如果匹配的话，则以<replacement>;替换。这里，<pattern>;可以包括通配符“%”，表示任意长度的字串。如果<replacement>;中也包含“%”，那么，<replacement>;中的这个“%”将是<pattern>;中的那个“%”所代表的字串。（可以用“\”来转义，以“\%”来表示真实含义的“%”字符） 
 返回：函数返回被替换过后的字符串。 

 示例： 

 $(patsubst %.c,%.o,x.c.c bar.c) 

 把字串“x.c.c bar.c”符合模式[%.c]的单词替换成[%.o]，返回结果是“x.c.o bar.o” 

 备注： 

 这和我们前面“变量章节”说过的相关知识有点相似。如： 

 “$(var:<pattern>;=<replacement>;)” 
 相当于 
 “$(patsubst <pattern>;,<replacement>;,$(var))”， 

 而“$(var: <suffix>;=<replacement>;)” 
 则相当于 
 “$(patsubst %<suffix>;,%<replacement>;,$(var))”。 

 例如有：objects = foo.o bar.o baz.o， 
 那么，“$(objects:.o=.c)”和“$(patsubst %.o,%.c,$(objects))”是一样的。 

$(strip <string>;) 

 名称：去空格函数——strip。 
 功能：去掉<string>;字串中开头和结尾的空字符。 
 返回：返回被去掉空格的字符串值。 
 示例： 
 
 $(strip a b c ) 

 把字串“a b c ”去到开头和结尾的空格，结果是“a b c”。 

$(findstring <find>;,<in>;) 

 名称：查找字符串函数——findstring。 
 功能：在字串<in>;中查找<find>;字串。 
 返回：如果找到，那么返回<find>;，否则返回空字符串。 
 示例： 

 $(findstring a,a b c) 
 $(findstring a,b c) 

 第一个函数返回“a”字符串，第二个返回“”字符串（空字符串） 


 

“environment” 

 如果<variable>;是一个环境变量，并且当Makefile被执行时，“-e”参数没有被打开。 

 

“file” 

 如果<variable>;这个变量被定义在Makefile中。 

 

“command line” 

 如果<variable>;这个变量是被命令行定义的。 

 

“override” 

 如果<variable>;是被override指示符重新定义的。 

 

“automatic” 

 如果<variable>;是一个命令运行中的自动化变量。关于自动化变量将在后面讲述。 

 

这些信息对于我们编写Makefile是非常有用的，例如，假设我们有一个Makefile其包了一个定义文件Make.def，在Make.def中定义了一个变量“bletch”，而我们的环境中也有一个环境变量“bletch”，此时，我们想判断一下，如果变量来源于环境，那么我们就把之重定义了，如果来源于Make.def或是命令行等非环境的，那么我们就不重新定义它。于是，在我们的Makefile中，我们可以这样写： 

 

 ifdef bletch 

 ifeq "$(origin bletch)" "environment" 

 bletch = barf, gag, etc. 

 endif 

 endif 

 

当然，你也许会说，使用override关键字不就可以重新定义环境中的变量了吗？为什么需要使用这样的步骤？是的，我们用override是可以达到这样的效果，可是override过于粗暴，它同时会把从命令行定义的变量也覆盖了，而我们只想重新定义环境传来的，而不想重新定义命令行传来的。 

 

 

八、shell函数 
 

shell函数也不像其它的函数。顾名思义，它的参数应该就是操作系统Shell的命令。它和反引号“`”是相同的功能。这就是说，shell函数把执行操作系统命令后的输出作为函数返回。于是，我们可以用操作系统命令以及字符串处理命令awk，sed等等命令来生成一个变量，如： 

 

 contents := $(shell cat foo) 

 

 files := $(shell echo *.c) 

 

注意，这个函数会新生成一个Shell程序来执行命令，所以你要注意其运行性能，如果你的Makefile中有一些比较复杂的规则，并大量使用了这个函数，那么对于你的系统性能是有害的。特别是Makefile的隐晦的规则可能会让你的shell函数执行的次数比你想像的多得多。 

 

 

九、控制make的函数 
 

make提供了一些函数来控制make的运行。通常，你需要检测一些运行Makefile时的运行时信息，并且根据这些信息来决定，你是让make继续执行，还是停止。 

 

$(error <text ...>;) 

 

 产生一个致命的错误，<text ...>;是错误信息。注意，error函数不会在一被使用就会产生错误信息，所以如果你把其定义在某个变量中，并在后续的脚本中使用这个变量，那么也是可以的。例如： 

 

 示例一： 

 ifdef ERROR_001 

 $(error error is $(ERROR_001)) 

 endif 

 

 示例二： 

 ERR = $(error found an error!) 

 .PHONY: err 

 err: ; $(ERR) 

 

 示例一会在变量ERROR_001定义了后执行时产生error调用，而示例二则在目录err被执行时才发生error调用。 

 

$(warning <text ...>;) 

 

 这个函数很像error函数，只是它并不会让make退出，只是输出一段警告信息，而make继续执行。

 

“environment” 

 如果<variable>;是一个环境变量，并且当Makefile被执行时，“-e”参数没有被打开。 

 

“file” 

 如果<variable>;这个变量被定义在Makefile中。 

 

“command line” 

 如果<variable>;这个变量是被命令行定义的。 

 

“override” 

 如果<variable>;是被override指示符重新定义的。 

 

“automatic” 

 如果<variable>;是一个命令运行中的自动化变量。关于自动化变量将在后面讲述。 

 

这些信息对于我们编写Makefile是非常有用的，例如，假设我们有一个Makefile其包了一个定义文件Make.def，在Make.def中定义了一个变量“bletch”，而我们的环境中也有一个环境变量“bletch”，此时，我们想判断一下，如果变量来源于环境，那么我们就把之重定义了，如果来源于Make.def或是命令行等非环境的，那么我们就不重新定义它。于是，在我们的Makefile中，我们可以这样写： 

 

 ifdef bletch 

 ifeq "$(origin bletch)" "environment" 

 bletch = barf, gag, etc. 

 endif 

 endif 

 

当然，你也许会说，使用override关键字不就可以重新定义环境中的变量了吗？为什么需要使用这样的步骤？是的，我们用override是可以达到这样的效果，可是override过于粗暴，它同时会把从命令行定义的变量也覆盖了，而我们只想重新定义环境传来的，而不想重新定义命令行传来的。 

 

 

八、shell函数 
 

shell函数也不像其它的函数。顾名思义，它的参数应该就是操作系统Shell的命令。它和反引号“`”是相同的功能。这就是说，shell函数把执行操作系统命令后的输出作为函数返回。于是，我们可以用操作系统命令以及字符串处理命令awk，sed等等命令来生成一个变量，如： 

 

 contents := $(shell cat foo) 

 

 files := $(shell echo *.c) 

 

注意，这个函数会新生成一个Shell程序来执行命令，所以你要注意其运行性能，如果你的Makefile中有一些比较复杂的规则，并大量使用了这个函数，那么对于你的系统性能是有害的。特别是Makefile的隐晦的规则可能会让你的shell函数执行的次数比你想像的多得多。 

 

 

九、控制make的函数 
 

make提供了一些函数来控制make的运行。通常，你需要检测一些运行Makefile时的运行时信息，并且根据这些信息来决定，你是让make继续执行，还是停止。 

 

$(error <text ...>;) 

 

 产生一个致命的错误，<text ...>;是错误信息。注意，error函数不会在一被使用就会产生错误信息，所以如果你把其定义在某个变量中，并在后续的脚本中使用这个变量，那么也是可以的。例如： 

 

 示例一： 

 ifdef ERROR_001 

 $(error error is $(ERROR_001)) 

 endif 

 

 示例二： 

 ERR = $(error found an error!) 

 .PHONY: err 

 err: ; $(ERR) 

 

 示例一会在变量ERROR_001定义了后执行时产生error调用，而示例二则在目录err被执行时才发生error调用。 

 

$(warning <text ...>;) 

 

 这个函数很像error函数，只是它并不会让make退出，只是输出一段警告信息，而make继续执行。

隐含规则 
———— 

在我们使用Makefile时，有一些我们会经常使用，而且使用频率非常高的东西，比如，我们编译C/C++的源程序为中间目标文件（Unix下是[.o]文件，Windows下是[.obj]文件）。本章讲述的就是一些在Makefile中的“隐含的”，早先约定了的，不需要我们再写出来的规则。 

“隐含规则”也就是一种惯例，make会按照这种“惯例”心照不喧地来运行，那怕我们的Makefile中没有书写这样的规则。例如，把[.c]文件编译成[.o]文件这一规则，你根本就不用写出来，make会自动推导出这种规则，并生成我们需要的[.o]文件。 

“隐含规则”会使用一些我们系统变量，我们可以改变这些系统变量的值来定制隐含规则的运行时的参数。如系统变量“CFLAGS”可以控制编译时的编译器参数。 

我们还可以通过“模式规则”的方式写下自己的隐含规则。用“后缀规则”来定义隐含规则会有许多的限制。使用“模式规则”会更回得智能和清楚，但“后缀规则”可以用来保证我们Makefile的兼容性。 
我们了解了“隐含规则”，可以让其为我们更好的服务，也会让我们知道一些“约定俗成”了的东西，而不至于使得我们在运行Makefile时出现一些我们觉得莫名其妙的东西。当然，任何事物都是矛盾的，水能载舟，亦可覆舟，所以，有时候“隐含规则”也会给我们造成不小的麻烦。只有了解了它，我们才能更好地使用它。 


一、使用隐含规则 

如果要使用隐含规则生成你需要的目标，你所需要做的就是不要写出这个目标的规则。那么，make会试图去自动推导产生这个目标的规则和命令，如果make可以自动推导生成这个目标的规则和命令，那么这个行为就是隐含规则的自动推导。当然，隐含规则是make事先约定好的一些东西。例如，我们有下面的一个Makefile： 

 foo : foo.o bar.o 
 cc –o foo foo.o bar.o $(CFLAGS) $(LDFLAGS) 

我们可以注意到，这个Makefile中并没有写下如何生成foo.o和bar.o这两目标的规则和命令。因为make的“隐含规则”功能会自动为我们自动去推导这两个目标的依赖目标和生成命令。 

make会在自己的“隐含规则”库中寻找可以用的规则，如果找到，那么就会使用。如果找不到，那么就会报错。在上面的那个例子中，make调用的隐含规则是，把[.o]的目标的依赖文件置成[.c]，并使用C的编译命令“cc –c $(CFLAGS) [.c]”来生成[.o]的目标。也就是说，我们完全没有必要写下下面的两条规则： 

 foo.o : foo.c 
 cc –c foo.c $(CFLAGS) 
 bar.o : bar.c 
 cc –c bar.c $(CFLAGS) 

因为，这已经是“约定”好了的事了，make和我们约定好了用C编译器“cc”生成[.o]文件的规则，这就是隐含规则。 

当然，如果我们为[.o]文件书写了自己的规则，那么make就不会自动推导并调用隐含规则，它会按照我们写好的规则忠实地执行。 

还有，在make的“隐含规则库”中，每一条隐含规则都在库中有其顺序，越靠前的则是越被经常使用的，所以，这会导致我们有些时候即使我们显示地指定了目标依赖，make也不会管。如下面这条规则（没有命令）： 

 foo.o : foo.p 

依赖文件“foo.p”（Pascal程序的源文件）有可能变得没有意义。如果目录下存在了“foo.c”文件，那么我们的隐含规则一样会生效，并会通过“foo.c”调用C的编译器生成foo.o文件。因为，在隐含规则中，Pascal的规则出现在C的规则之后，所以，make找到可以生成foo.o的C的规则就不再寻找下一条规则了。如果你确实不希望任何隐含规则推导，那么，你就不要只写出“依赖规则”，而不写命令。 


二、隐含规则一览 

这里我们将讲述所有预先设置（也就是make内建）的隐含规则，如果我们不明确地写下规则，那么，make就会在这些规则中寻找所需要规则和命令。当然，我们也可以使用make的参数“-r”或“--no-builtin-rules”选项来取消所有的预设置的隐含规则。 


mark

赞一个，这一下可以看好多开源软件了。