makefile关系到整个工程的编译规则，一个工程中的源文件不计其数，按其类型、功能、模块分别放在若干的目录当中，makefile制定了一系列的规则来指定哪些文件需要先编译，哪些文件需要后编译，哪一些文件需要重新编译。甚至于进行更复杂的功能操作。因为makefile就像一个shell脚本一样，其中也可以执行操作系统的命令。makefile带来的好处是自动化编译。
1. 关于程序的编译和连接
通常，无论是C、C++，首先把源文件编译成中间代码文件，即.o文件。这个动作叫做编译(compile)。然后再把大量的中间文件(Object File)合成执行文件，这个动作叫做**链接(link)**。
编译时，编译器需要的是语法的正确，函数与变量的声明正确。对于后者，通常是你需要告诉编译器头文件的所在位置(头文件中应该只是声明，而定义放在C/C++文件当中)。只要所有的语法正确，编译器就可以编译出正确的中间目标文件。一般来说，每一个源文件都应该对应于一个目标文件。
链接时，主要是链接函数和全局变量，所以，我们可以使用这些中间目标文件(O或者是OBJ文件)来链接我们的应用程序。连接器并不管函数所在的源文件，只管函数的中间目标文件(Object File),在大多数的时候，由于源文件太多，编译生成的中间目标文件太多。在大多数的时候，由于源文件太多，编译生成的中间目标文件太多。而在链接是需要明显的指出中间目标文件的名字，这对于编译来说很不方便。所以，我们要给中间目标文件打个包，在Windows下这种包叫库文件(Library File),也就是.lib，在UNIX下，时Archive File,也就是.a文件。
总结：源文件首先会生成目标文件，再由目标文件生成执行文件。在编译时，编译器只检测程序语法，和函数、变量是否被声明。如果函数未被声明，编译器会给出一个警告，但是可以生成Object File。而在链接是，链接器会在所有的Object File中寻找函数的实现，如果找不到，那就会报链接错误。
MakeFile介绍
make命令执行时，需要一个 Makefile 文件，以告诉make命令需要怎么样的去编译和链接程序。
makefile 规则
target...:prerequisites...
command
...
target也就是一个目标文件，也就是Object File，也可以是执行文件。还可以是一个标签(Label),对于标签这种特性，在后续的伪目标章节会有叙述。
prerequisites就是要生成那个target所需要的文件或者是依赖。
command就是make需要执行的命令。(任意的shell命令)
这是一个文件的依赖关系，也就是说，target这一个或多个的目标文件依赖于prerequisites中的文件，其生成规则定义在command中。prerequisites中如果有一个以上的文件比target文件要新的话，command所定义的命令就会被执行。这就是Makefile的规则。也就是Makefile中最核心的内容。
** make并不管命令是怎么工作的，他只管执行所定义的命令。**make会比较targets文件和prerequisites文件的修改日期，如果prerequisites文件的日期要比targets文件的日期要新，或者target不存在的话，那么，make就会执行后续定义的命令。
这里要说明一点的是，clean不是一个文件，它只不过是一个动作名字，有点像C语言中的lable一样，其冒号后什么也没有，那么，make就不会自动去找文件的依赖性，也就不会自动执行其后所定义的命令。要执行其后的命令，就要在make命令后明显得指出这个lable的名字。这样的方法非常有用，我们可以在一个makefile中定义不用的编译或是和编译无关的命令，比如程序的打包，程序的备份，等等。
make是如何工作的
- make会在当前目录下找名字叫“Makefile”或“makefile”的文件
- 如果找到，它会找文件中的第一个目标文件（target），在上面的例子中，他会找到“edit”这个文件，并把这个文件作为最终的目标文件。
- 如果edit文件不存在，或是edit所依赖的后面的 .o 文件的文件修改时间要比edit这个文件新，那么，他就会执行后面所定义的命令来生成edit这个文件。
- 如果edit所依赖的.o文件也不存在，那么make会在当前文件中找目标为.o文件的依赖性，如果找到则再根据那一个规则生成.o文件。（这有点像一个堆栈的过程）
- 当然，你的C文件和H文件是存在的啦，于是make会生成 .o 文件，然后再用 .o 文件声明make的终极任务，也就是执行文件edit了
这就是整个make的依赖性，make会一层又一层地去找文件的依赖关系，直到最终编译出第一个目标文件。在找寻的过程中，如果出现错误，比如最后被依赖的文件找不到，那么make就会直接退出，并报错，而对于所定义的命令的错误，或是编译不成功，make根本不理。make只管文件的依赖性，即，如果在我找了依赖关系之后，冒号后面的文件还是不在，那么make就会出错。
让make自动推导
GNU的make很强大，可以自动推导文件以及文件依赖关系后面的命令，于是我们就没有必要在每一个 .o文件后都写上类似的命令。只要make看到一个.o文件，它就会自动把.c文件加在依赖关系当中，如果make找到一个whatever.o，那么whatever.c就会是其依赖文件，并且还会自动推导出cc -c whatever.c如：
target : $(objects)
CC -o target $(objects)
main.o ：defs.h
kbd.o ：defs.h
command.o : defs.h command.h
...
.PHONY : clean
clean:
rm target $(objects)
这种方法就是makefile的隐晦规则，上面的文件中的.PHONY表示，clean是个伪目标。
另类风格的makefile
既然makefile可以自动推导，那么有那么多重复的.h文件是否可将其合并起来呢。当然可以。如下：
objects = main.o kdb.o command.o display.o insert.o search.o files.o utils.o
target : $(objects)
CC -o target $(objects)
$(objects): defs.h
kbd.o command.o files.o : cammand.h
display.o insert.o search.o files.o : buffer.h
.PHONY : clean
clean:
-rm - rf target $(objects)
这种风格让makefile变得简单，但是我们的依赖文件就变得凌乱。选择哪种看自己的爱好。这种的风格依赖关系看不清楚，另外如果文件一多，要加入几个新的.o文件，那就会理不清关系。
Makefile总述
Makefile里面主要包含了五个东西：显式规则、隐晦规则、变量定义、文件指示和注释。
- 显式规则：说明了如何生成一个或多的的目标文件。这是由Makefile的书写者明显指出，要生成的文件，文件的依赖文件，生成的命令。
- 隐晦规则：由于我们的make有自动推导的功能，所以隐晦的规则可以让我们比较粗糙地简略地书写Makefile，这是由make所支持的。
- 变量的定义：在Makefile中我们要定义一系列的变量，变量一般都是字符串，这个有点你C语言中的宏，当Makefile被执行时，其中的变量都会被扩展到相应的引用位置上。
- 文件指示：其包括了三个部分，一个是在一个Makefile中引用另一个Makefile，就像C语言中的include一样；另一个是指根据某些情况指定Makefile中的有效部分，就像C语言中的预编译#if一样；还有就是定义一个多行的命令。
- 注释：Makefile中只有行注释，和UNIX的shell脚本一样，其注释是用#字符，若要在makefile中使用“#”字符，可以使用反斜框进行转义，如“#”。
通常使用makefile、Makefile、GNUmakefile来命名你的makefile，但是也可以使用别的文件名来书写如：“Make.Linux”、"Make.Me"...等，如果使用的是这些makefile那么需要使用make -f或--file参数。例如：
make -f Make.Linux或者 make --file Make.Linux
在makefile当中引用别的makefile可以使用include关键字，语法为：include filenamefilename可以是当前的操作系统shell的文件模式(可以包含路径和通配符)
make命令开始时，会把找寻include所指出的其它Makefile，并把其内容安置在当前的位置。就好像C/C++的#include指令一样。如果文件都没有指定绝对路径或是相对路径的话，make会在当前目录下首先寻找，如果当前目录下没有找到，那么，make还会在下面的几个目录下找：
- 如果make执行时，有 -I或者是--include-dir参数，那么make就会在这几个参数所指定的目录下去寻找。
- 如果目录/include(一般是：/usr/local/bin或者是/usr/include)存在的话，make也会去寻找。
如果有文件没有找到的话，make会生成一条警告信息，但不会马上出现致命错误。它会继续载入其它的文件，一旦完成makefile的读取，make会再重试这些没有找到，或是不能读取的文件，如果还是不行，make才会出现一条致命信息。如果你想让make不理那些无法读取的文件，而继续执行，你可以在include前加一个减号“-”。如：-include<filename>
环境变量MAKEFILES
若你的当前环境中定义了环境变量MAKEFILES，那么make会把这个变量中的值做一个类似于include的动作。这个变量中的值是其他的Makefile，用空格分隔。只是它与makefile不同的是，从这个环境变量中引入的makefile的目标不会起作用，如果环境变量中定义的文件发现错误，make也不会处理。但是在这里我还是建议不要使用这个环境变量，因为只要这个变量一被定义，那么当你使用make时，所有的Makefile都会受到它的影响，这绝不是你想看到的。在这里提这个事，只是为了告诉大家，也许有时候你的Makefile出现了怪事，那么你可以看看当前环境中有没有定义这个变量。
make的工作方式
- 读入所有的Makefile.
- 读入被include的其他的Makefile。
- 初始化文件中的变量。
- 推导隐晦规则，并分析所有的规则。
- 为所有的目标文件创建依赖关系链。
- 依据依赖关系，决定哪些目标要重新生成。
- 执行生成命令。
1-5步为第一个阶段，6-7为第二个阶段。第一个阶段中，如果定义的变量被使用了，那么，make会把其展开在使用的位置。但make并不会完全马上展开，make使用的是拖延战术，如果变量出现在依赖关系的规则中，那么仅当这条依赖被决定要使用了，变量才会在其内部展开。当然，这个工作方式你不一定要清楚，但是知道这个方式你也会对make更为熟悉。有了这个基础，后续部分也就容易看懂了。
Makefile书写规则
规则包含两个部分，一个是依赖关系，一个是生成目标的方法。
在Makefile中，规则的顺序是很重要的，因为，Makefile中只应该有一个最终目标，其它的目标都是被这个目标所连带出来的，所以一定要让make知道你的最终目标是什么。一般来说，定义在Makefile中的目标可能会有很多，但是第一条规则中的目标将被确立为最终的目标。如果第一条规则中的目标有很多个，那么，第一个目标会成为最终的目标。make所完成的也就是这个目标。
- 文件的依赖关系，foo.o依赖于foo.c和defs.h的文件，如果foo.c和defs.h的文件日期要比foo.o文件日期要新，或是foo.o不存在，那么依赖关系发生。
- 如果生成（或更新）foo.o文件。也就是那个cc命令，其说明了，如何生成foo.o这个文件。（当然foo.c文件include了defs.h文件）
在规则中使用通配符
make支持三种通配符"","?","[...]".这是和UNIX的B-shell是相同的。
例如：objects= *.o
上面这个例子有点特殊，在使用时表示objects变量都会被替换为.o，但是.o并不会被展开，也就是让objects的值就是.o，而不是所有.o结尾的文件。若想要让通配符在变量中展开，那么你可以这样做：
objects:=$(wildcard *.o)
这种使用方法由关键字"wildcard"指出，关于Makefile的关键字，我们将会在后面讨论。
文件搜寻
Makefile文件中的特殊变量“VPATH”就是完成这个功能的，如果没有指明这个变量，make只会在当前的目录中去找寻依赖文件和目标文件。如果定义了这个变量，那么，make就会在当当前目录找不到的情况下，到所指定的目录中去找寻文件了。例如：VPATH = src : ../headers指定了两个目录，"src"和"../headers".make会按照这个顺序进行搜索。目录由“冒号”分隔。(当然，当前的目录永远是最高优先级搜索目录)
另一个设置文件搜索路径的方法是使用make的“vpath”关键字（注意，它是全小写的），这不是变量，这是一个make的关键字，这和上面提到的那个VPATH变量很类似，但是它更为灵活。它可以指定不同的文件在不同的搜索目录中。这是一个很灵活的功能。它的使用方法有三种：
- vpath < pattern> < directories> 为符合模式< pattern>的文件指定搜索目录<directories>。
- vpath < pattern> 清除符合模式< pattern>的文件的搜索目录。
- vpath 清除所有已被设置好了的文件搜索目录。
vapth使用方法中的< pattern>需要包含“%”字符。“%”的意思是匹配零或若干字符，例如，“%.h”表示所有以“.h”结尾的文件。< pattern>指定了要搜索的文件集，而< directories>则指定了的文件集的搜索的目录。例如：vpath %.h ../headers
该语句表示，要求make在“../headers”目录下搜索所有以“.h”结尾的文件。（如果某文件在当前目录没有找到的话）
我们可以连续地使用vpath语句，以指定不同搜索策略。如果连续的vpath语句中出现了相同的< pattern>，或是被重复了的< pattern>，那么，make会按照vpath语句的先后顺序来执行搜索。如：
vpath %.c foo
vpath % blish
vpath %.c bar
其表示“.c”结尾的文件，先在“foo”目录，然后是“blish”，最后是“bar”目录。
vpath %.c foo:bar
vpath % blish
而上面的语句则表示.c结尾的文件，现在"foo"目录，然后是"bar"目录，左后才是"blish"目录。
伪目标
伪目标一般没有依赖的文件。但是我们也可以为伪目标指定所依赖的文件。伪目标同样可以作为"默认目标"，只要将其放在第一个位置。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”，意思是我们的集合中都是以“.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”的“%”，也就是“foobar”，并为其加下“.c”的后缀，于是，我们的依赖目标就是“foo.cbar.c”。而命令中的“$<”和“$@”则是自动化变量，“$<”表示所有的依赖目标集（也就是“foo.c bar.c”），“$@”表示目标集（也褪恰癴oo.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"那么依赖关系应该是：main.o : main.c defs.h但是若是一个大型的工程，你必须要清楚的知道哪一些C文件包含了哪一些头文件，并且在你加入或者是删除头文件的时候，也需要小心地修改Makefile，为了避免这种工作，我们可以使用C/C++编译的一个功能。大多数的C/C++编译器都支持一个-M选项，即自动寻找源文件中包含的头文件，并生成一个依赖关系。
例如：如果我们执行下面的命令：cc -M[/-MM] main.c 其输出是：main.o : main.c defs.h于是由编译器自动生成的依赖关系，这样一来，你就不必再手动书写若干文件的依赖关系，而由编译器自动生成了。需要提醒一句的是，如果你使用GNU的C/C++编译器，你得用-MM参数，不然，-M参数会把一些标准库的头文件也包含进来。
- 那么，编译器的这个功能如何与我们的Makefile联系在一起呢。因为这样一来，我们的Makefile也要根据这些源文件重新生成，让Makefile自已依赖于源文件？这个功能并不现实，不过我们可以有其它手段来迂回地实现这一功能。GNU组织建议把编译器为每一个源文件的自动生成的依赖关系放到一个文件中，为每一个“name.c”的文件都生成一个“name.d”的Makefile文件，[.d]文件中就存放对应[.c]文件的依赖关系。于是，我们可以写出[.c]文件和[.d]文件的依赖关系，并让make自动更新或自动生成[.d]文件，并把其包含在我们的主Makefile中，这样，我们就可以自动化地生成每个文件的依赖关系了。
这里我们给出一个模式规则来产生[.d]文件：
%.d : %.c
@set -e; rm -f $@;$(CC) -MM $(CPPFLAGS) $< > $@;
sed's,$*\.o[:]*,\1.o $@:,g' < $@.
>$@; rm -f $@.
这个规则的意思是，所有的.d文件都依赖于[.c]文件，rm -f $@的意思是删除所有的目标，也就是[.d]文件，第二行的意思是，为每一个依赖文件$<,也就是[.c]文件生成依赖关系，$@表示模式%.d文件，如果有一个C文件是name.c,那么"%"就是"name"," "意为随机生成一个编号，第二行生成的文档可能是"name.d.12345",第三行使用sed命令做了一个替换，第四行就是删除临时文件。总而言之，这个模式要做的事情就是在编译器生成的依赖关系中加入[.d]文件的依赖，即把依赖关系：main.o:main.c defs.h
使用变量
在Makefile中定义的变量，就像是C/C++语言中的宏一样，他代表了一个文本字串，在Makefile中执行的时候其会自动原模原样的展开在所使用的地方与其C/C++不同的是，你可以在Makefile中改变其值。在makefile中，变量可以使用在“目标”、“依赖目标”、“命令”或者是makefile中的其他部分.makefile的变量是大小写敏感的，传统的makefile的变量名是全大写的命名方式
1.变量的基础
变量在声明的时候需要给予初值，而在使用的时候，需要在加上“$”符号，但最好用小括号“（）”或是大括号“{}”把变量给包括起来。给变量加一个括号完全是为了更加安全的使用这个变量。如果你要使用真实的“$”字符，那么你需要用“$$”来表示。变量可以使用在许多地方，如规则中的“目标”、“依赖”、“命令”以及新的变量中。变量的值可以在任何的地方定义，不要求变量的定义在变量的使用之前。
2. 变量中的变量
在定义变量的时候，我们可以使用其他的变量来够着变量的值，在Makefile中有两种方式来在用变量定义的值。
隐含规则
在我们使用makefile时，有一些我们经常会使用，而且频率非常高的东西，比如编译C/C++的源程序为中间目标文件(.o)
隐含规则也就是一种惯例，make会按照这种“惯例”心照不宣的来工作，即使在makefile中没有书写这种规则。例如把.c编译成.o这一规则make会自动推导出来，并生成我们所需要的.o文件。隐含规则会使用一些我们的系统变量，我们可以改变这些系统变量的值来定制隐含规则的运行时参数。如系统变量"CFLAGS"可以控制编译时的编译器参数。
我们还可以通过“模式规则”的方式写下自己的隐含规则。用“后缀规则”来定义隐含规则会有许多的限制。使用“模式规则”会更回得智能和清楚，但“后缀规则”可以用来保
证我们Makefile的兼容性。
我们了解了“隐含规则”，可以让其为我们更好的服务，也会让我们知道一些“约定俗成”了的东西，而不至于使得我们在运行Makefile时出现一些我们觉得莫名其妙的东西。当然，任何事物都是矛盾的，水能载舟，亦可覆舟，所以，有时候“隐含规则”也会给我们造成不小的麻烦。只有了解了它，我们才能更好地使用它。
使用隐含规则
若要使用隐含规则生成你所需要的目标，你所要做的就是不要写出这个目标的规则。那么，make就会试图自动推导产生这个目标的规则和命令。例如：
foo:foo.o bar.o
cc -o foo foo.o bar.o $(CFLAGS) $(LDFLAGS)
上面这个例子并没有写下如何生成foo.o和bar.o这两个目标的规则和命令。因为make的“隐晦规则”功能会自动为我们去推导这两个目标的依赖和生成命令。make 会在自己的“隐含规则”库中寻找可以用的规则，如果找到，那么就会使用。如果找不到，那么就会报错。在上面的那个例子中，make调用的隐含规则是，把 [.o]的目标的依赖文件置成[.c]，并使用C的编译命令“cc –c $(CFLAGS) [.c]”来生成[.o]的目标。
网友评论