Makefile 可以简单的认为是一个工程文件的编译规则，描述了整个工程的编译和链接等规则。其中包含了那些文件需要编译，那些文件不需要编译，那些文件需要先编译，那些文件需要后编译，那些文件需要重建等等。编译整个工程需要涉及到的，在 Makefile 中都可以进行描述。换句话说，Makefile 可以使得我们的项目工程的编译变得自动化，不需要每次都手动输入一堆源文件和参数。

以 Linux 下的C语言开发为例来具体说明一下，多文件编译生成一个文件，编译的命令如下所示：

下面是一些常用的隐含规则：

• 汇编和需要预处理的汇编程序

• Lex C 程序时的隐含规则

上面的编译顺序都是一些常用的编程语言执行隐含规则的顺序，我们在 Makefile 中指定规则时，可以参考这样的列表。当需要编译源文件的时候，考虑是不是需要使用隐含规则。如果不需要，就要把相应的规则和命令全部书写上去。

内嵌隐含规则的命令中，所使用的变量都是预定义的。我们将这些变量称为“隐含变量”。这些变量允许修改：可以通过命令行参数传递或者是设置系统环境变量的方式都可以对它进行重新定义。无论使用哪种方式，只要 make 在运行的，这些变量的定义有效。Makefile 的隐含规则都会使用到这些变量。

比如我们编译 .c 文件在我们的 Makefile 中就是隐含的规则，默认使用到的编译命令时cc，执行的命令时cc -c我们可以对用上面的任何一种方式将CC定义为ncc。这样我们就编译 .c 文件的时候就可以用ncc进行编译。

隐含规则中使用的变量可以分成两类：

1.代表一个程序的名字。例如：“CC”代表了编译器的这个可执行程序。

2.代表执行这个程序使用的参数.例如：变量“CFLAGS”。多个参数之间使用空格隔开。

下面我们来列举一下代表命令的变量，默认都是小写。

• AR：函数库打包程序，科创价静态库 .a 文档。

• AS：应用于汇编程序。

• CO：从 RCS 中提取文件的程序。

• CPP：C程序的预处理器。

• FC：编译器和与处理函数 Fortran 源文件的编译器。

• GET：从CSSC 中提取文件程序。

• YACC：Yacc 文法分析器（针对于C语言）

日常使用 Makefile 编译文件时，可能会遇到需要分条件执行的情况，比如在一个工程文件中，可编译的源文件很多，但是它们的类型是不相同的，所以编译文件使用的编译器也是不同的。手动编译去操作文件显然是不可行的（每个文件编译时需要注意的事项很多），所以 make 为我们提供了条件判断来解决这样的问题。

需要解决的问题：要根据判断，分条件执行语句。

条件语句的作用：条件语句可以根据一个变量的值来控制 make 执行或者时忽略 Makefile 的特定部分，条件语句可以是两个不同的变量或者是常量和变量之间的比较。

条件语句使用优点：Makefile 中使用条件控制可以做到处理的灵活性和高效性。注意：条件语句只能用于控制 make 实际执行的 Makefile 文件部分，不能控制规则的 shell 命令执行的过程。

下面是条件判断中使用到的一些关键字：

条件判断的使用方式如下：

条件语句中使用到三个关键字“ifeq”、“else”、“endif”。其中：“ifeq”表示条件语句的开始，并指定一个比较条件（相等）。括号和关键字之间要使用空格分隔，两个参数之间要使用逗号分隔。参数中的变量引用在进行变量值比较的时候被展开。“ifeq”，后面的是条件满足的时候执行的，条件不满足忽略；“else”表示当条件不满足的时候执行的部分，不是所有的条件语句都要执行此部分；“endif”是判断语句结束标志，Makefile 中条件判断的结束都要有。

其实 "ifneq" 和 "ifeq" 的使用方法是完全相同的，只不过是满足条件后执行的语句正好相反。

上面的例子可以换一种更加简介的方式来写：

它的主要功能是判断变量的值是不是为空，实例：

通过两个实例对比说明：通过打印 "yes" 或 "no" 来演示执行的结果。我们执行 make 可以看到实例 1打印的结果是 "yes" ，实例 2打印的结果是 "no" 。其原因就是在实例 1 中，变量“foo”的定义是“foo = $(bar)”。虽然变量“bar”的值为空，但是“ifdef”的判断结果为真，这种方式判断显然是有不行的，因此当我们需要判断一个变量的值是否为空的时候需要使用“ifeq" 而不是“ifdef”。

注意：在 make 读取 Makefile 文件时计算表达式的值，并根据表达式的值决定判断语句中的哪一个部分作为此 Makefile 所要执行的内容。因此在条件表达式中不能使用自动化变量，自动化变量在规则命令执行时才有效，更不能将一个完整的条件判断语句分卸在两个不同的 Makefile 的文件中。在一个 Makefile 中使用指示符 "include" 包含另一个 Makefile

伪目标可以这样来理解，它并不会创建目标文件，只是想去执行这个目标下面的命令。伪目标的存在可以帮助我们找到命令并执行。

使用伪目标有两点原因：

• 避免我们的 Makefile 中定义的只执行的命令的目标和工作目录下的实际文件出现名字冲突。

• 提高执行 make 时的效率，特别是对于一个大型的工程来说，提高编译的效率也是我们所必需的。

我们先来看一下第一种情况的使用。如果需要书写这样一个规则，规则所定义的命令不是去创建文件，而是通过 make 命令明确指定它来执行一些特定的命令。实例：

规则中 rm 命令不是创建文件 clean 的命令，而是执行删除任务，删除当前目录下的所有的 .o 结尾和文件名为 test 的文件。当工作目录下不存在以 clean 命令的文件时，在 shell 中输入 make clean 命令，命令 rm -rf *.o test 总会被执行 ，这也是我们期望的结果。

如果当前目录下存在文件名为 clean 的文件时情况就会不一样了，当我们在 shell 中执行命令 make clean，由于这个规则没有依赖文件，所以目标被认为是最新的而不去执行规则所定义的命令。因此命令 rm 将不会被执行。为了解决这个问题，删除 clean 文件或者是在 Makefile 中将目标 clean 声明为伪目标。将一个目标声明称伪目标的方法是将它作为特殊的目标.PHONY的依赖，如下：

这样 clean 就被声明成一个伪目标，无论当前目录下是否存在 clean 这个文件，当我们执行 make clean 后 rm 都会被执行。而且当一个目标被声明为伪目标之后，make 在执行此规则时不会去试图去查找隐含的关系去创建它。这样同样提高了 make 的执行效率，同时也不用担心目标和文件名重名而使我们的编译失败。

在书写伪目标的时候，需要声明目标是一个伪目标，之后才是伪目标的规则定义。目标 "clean" 的完整书写格式如下：

伪目标的另一种使用的场合是在 make 的并行和递归执行的过程中，此情况下一般会存在一个变量，定义为所有需要 make 的子目录。对多个目录进行 make 的实现，可以在一个规则的命令行中使用 shell 循环来完成。如下：

代码表达的意思是当前目录下存在三个子文件目录，每个子目录文件都有相对应的 Makefile 文件，代码中实现的部分是用当前目录下的 Makefile 控制其它子模块中的 Makefile 的运行，但是这种实现方法存在以下几个问题：

• 当子目录执行 make 出现错误时，make 不会退出。就是说，在对某个目录执行 make 失败以后，会继续对其他的目录进行 make。在最终执行失败的情况下，我们很难根据错误提示定位出具体实在那个目录下执行 make 发生的错误。这样给问题定位造成很大的困难。为了解决问题可以在命令部分加入错误检测，在命令执行的错误后主动退出。不幸的是如果在执行 make 时使用了 "-k"

• 另外一个问题就是使用这种 shell 循环方式时，没有用到 make 对目录的并行处理功能由于规则的命令时一条完整的 shell 命令，不能被并行处理。

有了伪目标之后，我们可以用它来克服以上方式所存在的两个问题，代码展示如下：

上面的实例中有一个没有命令行的规则“foo:baz”，这个规则是用来规定三个子目录的编译顺序。因为在规则中 "baz" 的子目录被当作成了 "foo" 的依赖文件，所以 "baz" 要比 "foo" 子目录更先执行，最后执行 "bar" 子目录的编译。

一般情况下，一个伪目标不作为另外一个目标的依赖。这是因为当一个目标文件的依赖包含伪目标时，每一次在执行这个规则伪目标所定义的命令都会被执行（因为它作为规则的依赖，重建规则目标时需要首先重建规则的所有依赖文件）。当一个伪目标没有任何目标（此目标是一个可被创建或者是已存在的文件）的依赖时，我们只能通过 make 的命令来明确的指定它的终极目标，执行它所在规则所定义的命令。例如 make

如果在一个文件里想要同时生成多个可执行文件，我们可以借助伪目标来实现。使用方式如下：

我们在当前目录下创建了三个源文件，目的是把这三个源文件编译成为三个可执行文件。将重建的规则放到 Makefile 中，约定使用 "all" 的伪目标来作为最终目标，它的依赖文件就是要生成的可执行文件。这样的话只需要一个 make 命令，就会同时生成三个可执行文件。

之所以这样写，是因为伪目标的特性，它总会被执行，所以它依赖的三个文件的目标就不如 "all" 这个目标新，所以，其他的三个目标的规则总是被执行，这也就达到了我们一口气生成多个目标的目的。我们也可以实现单独的编译这三个中的任意一个源文件（我们想去重建 test1，我们可以执行命令make test1 来实现 ）。

Makefile常用字符串处理函数

函数的调用和变量的调用很像。引用变量的格式为$(变量名)，函数调用的格式如下：

其中，function 是函数名，arguments 是函数的参数，参数之间要用逗号分隔开。而参数和函数名之间使用空格分开。调用函数的时候要使用字符“$”，后面可以跟小括号也可以使用花括号。这个其实我们并不陌生，我们之前使用过许多的函数，比如说展开通配符的函数 wildcard，以及字符串替换的函数 patsubst ，Makefile 中函数并不是很多。

今天主要讲的是字符串处理函数，这些都是我们经常使用到的函数，下面是对函数详细的介绍。

1. 模式字符串替换函数，函数使用格式如下：

函数说明：函数功能是查找 text 中的单词是否符合模式 pattern，如果匹配的话，则用 replacement 替换。返回值为替换后的新字符串。实例：

执行 make 命令，我们可以得到的值是 "1.o 2.o 3.o"，这些都是替换后的值。

2. 字符串替换函数，函数使用格式如下：

函数说明：函数的功能是把字符串中的 form 替换成 to，返回值为替换后的新字符串。实例：

3. 去空格函数，函数使用格式如下：

函数说明：函数的功能是去掉字符串的开头和结尾的字符串，并且将其中的多个连续的空格合并成为一个空格。返回值为去掉空格后的字符串。实例：

执行完 make 之后，结果是“a b c”。这个只是除去开头和结尾的空格字符，并且将字符串中的空格合并成为一个空格。

4. 查找字符串函数，函数使用格式如下：

函数说明：函数的功能是查找 in 中的 find ,如果我们查找的目标字符串存在。返回值为目标字符串，如果不存在就返回空。实例：

执行 make 命令，得到的返回的结果就是 "a"。

5. 过滤函数，函数使用格式如下：

函数说明：函数的功能是过滤出 text 中符合模式 pattern 的字符串，可以有多个 pattern 。返回值为过滤后的字符串。实例：

执行 make 命令，我们得到的值是“1.c 2.o”。

6. 反过滤函数，函数使用格式如下：

函数说明：函数的功能是功能和 filter 函数正好相反，但是用法相同。去除符合模式 pattern 的字符串，保留符合的字符串。返回值是保留的字符串。实例：

执行 make 命令，打印的结果是“3.s”。

7. 排序函数，函数使用格式如下：

函数说明：函数的功能是将 <list>中的单词排序（升序）。返回值为排列后的字符串。实例：

执行 make 命令，我们得到的值是“bar foo lost”。注意：sort会去除重复的字符串。

8. 取单词函数，函数使用格式如下：

函数说明：函数的功能是取出函数<text>中的第n个单词。返回值为我们取出的第 n 个单词。实例：

执行 make 命令，我们得到的值是“2.c”。

Makefile常用文件名操作函数

我们在编写 Makefile 的时候，很多情况下需要对文件名进行操作。例如获取文件的路径，去除文件的路径，取出文件前缀或后缀等等。当遇到这样的问题的时手动修改是不太可能的，因为文件可能会很多，而且 Makefile 中操作文件名可能不止一次。所以 Makefile 给我们提供了相应的函数去实现文件名的操作。

注意：下面的每个函数的参数字符串都会被当作或是一个系列的文件名来看待。

1. 取目录函数，函数使用格式如下：

函数说明：函数的功能是从文件名序列 names 中取出目录部分，如果没有 names 中没有 "/" ，取出的值为 "./" 。返回值为目录部分，指的是最后一个反斜杠之前的部分。如果没有反斜杠将返回“./”。实例：

2. 取文件函数，函数使用格式如下：

函数说明：函数的功能是从文件名序列 names 中取出非目录的部分。非目录的部分是最后一个反斜杠之后的部分。返回值为文件非目录的部分。实例：

3. 取后缀名函数，函数使用格式如下：

函数说明：函数的功能是从文件名序列中 names 中取出各个文件的后缀名。返回值为文件名序列 names 中的后缀序列，如果文件没有后缀名，则返回空字符串。实例：

执行 make 命令，我们得到的值是“.c ”。文件 "hacks" 没有后缀名，所以返回的是空值。

4. 取前缀函数，函数使用格式如下：

函数说明：函数的功能是从文件名序列 names 中取出各个文件名的前缀部分。返回值为被取出来的文件的前缀名，如果文件没有前缀名则返回空的字符串。实例：

执行 make 命令，我们可以得到值是“src/foo hacks”。获取的是文件的前缀名，包含文件路径的部分。

5. 添加后缀名函数，函数使用格式如下：

函数说明：函数的功能是把后缀 suffix 加到 names 中的每个单词后面。返回值为添加上后缀的文件名序列。实例：

执行 make 后我们可以得到“sec/foo.c.c hack.c”。我们可以看到如果文件名存在后缀名，依然会加上。

6. 添加前缀名函数，函数使用格式如下：

函数说明：函数的功能是把前缀 prefix 加到 names 中的每个单词的前面。返回值为添加上前缀的文件名序列。实例：

执行 make 命令，我们可以得到值是 "src/foo.c src/hacks" 。我们可以使用这个函数给我们的文件添加路径。

7. 链接函数，函数使用格式如下：

函数说明：函数功能是把 list2 中的单词对应的拼接到 list1 的后面。如果 list1 的单词要比 list2的多，那么，list1 中多出来的单词将保持原样，如果 list1 中的单词要比 list2 中的单词少，那么 list2 中多出来的单词将保持原样。返回值为拼接好的字符串。实例：

8. 获取匹配模式文件名函数，命令使用格式如下：

函数说明：函数的功能是列出当前目录下所有符合模式的 PATTERN 格式的文件名。返回值为空格分隔并且存在当前目录下的所有符合模式 PATTERN 的文件名。实例：

执行 make 命令，可以得到当前函数下所有的 ".c " 和 ".h" 结尾的文件。这个函数通常跟的通配符 "*" 连用，使用在依赖规则的描述的时候被展开（在这里我们的例子如果没有 wildcard 函数，我们的运行结果也是这样，"echo" 属于 shell 命令，在使用通配符的时通配符自动展开，我们这里只是相要说明一下这个函数在使用时，如果通过引用变量出现在规则中要被使用）。

Makefile 中的其他的函数。以下是这些函数的详细说明。

函数的功能是：把参数<list>中的单词逐一取出放到参数<var>所指定的变量中，然后再执行<text>所包含的表达式。每一次<text>会返回一个字符串，循环过程中，<text>的返所返回的每个字符串会以空格分割，最后当整个循环结束的时候，<text>所返回的每个字符串所组成的整个字符串（以空格分隔）将会是

可见，if 函数可以包含else部分，或者是不包含，即if函数的参数可以是两个，也可以是三个。condition参数是 if 表达式，如果其返回的是非空的字符串，那么这个表达式就相当于返回真，于是，then-part就会被计算，否则else-part会被计算。

而if函数的返回值是：如果condition为真（非空字符串），那么then-part会是整个函数的返回值。如果condition为假（空字符串），那么else-part将会是这个函数的返回值。此时如果else-part没有被定义，那么整个函数返回空字串符。所以，then-part和else-part只会有一个被计算。

执行 make 命令我们可以得到函数的值是 foo.c，如果变量 OBJ 的值为空的话，我们得到的 OBJ 的值就是main.c。

call 函数是唯一一个可以用来创建新的参数化的函数。我们可以用来写一个非常复杂的表达式，这个表达式中，我们可以定义很多的参数，然后你可以用 call 函数来向这个表达式传递参数。

那么，foo 的值就是“a b”。当然，参数的次序可以是自定义的，不一定是顺序的，

此时的 foo 的值就是“b a”。

origin 函数不像其他的函数，它并不操作变量的值，它只是告诉你这个变量是哪里来的。注意： variable 是变量的名字，不应该是引用，所以最好不要在 variable 中使用“$”字符。origin 函数会员其返回值来告诉你这个变量的“出生情况”。

下面是origin函数返回值：

这些信息对于我们编写 Makefile 是非常有用的，例如假设我们有一个 Makefile ，其包含了一个定义文件Make.def，在Make.def中定义了一个变量bletch，而我们的环境变量中也有一个环境变量bletch，我们想去判断一下这个变量是不是环境变量，如果是我们就把它重定义了。如果是非环境变量，那么我们就不重新定义它。于是，我们在 Makefile

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

令是由 shell 命令行组成，他们是一条一条执行的。多个命令之间要使用分号隔开，Makefile 中的任何命令都要以tab键开始。多个命令行之间可以有空行和注释行，在执行规则时空行会被自动忽略。

通常系统中可能存在不同的 shell 。但是 make 处理 Makefile 过程时，如果没有明确的指定，那么对所有规则中的命令行的解析使用bin/sh来完成。执行过程中使用的 shell 决定了规则中的命令的语法和处理机制。当使用默认的bin/sh时，命令中出现的字符“#”到行末的内容被认为是注释。当然了“#”可以不在此行的行首，此时“#”之前的内容不会被作为注释处理。

通常 make 在执行命令行之前会把要是执行的命令行输出到标准输出设备。我们称之为 "回显"，就好像我们在 shell 环境下输入命令执行时一样。如果规则的命令行以字符“@”开始，则 make 在执行的时候就不会显示这个将要被执行的命令。典型的用法是在使用echo命令输出一些信息时。

我们在执行 make 时添加上一些参数，可以控制命令行是否输出。当使用 make 的时候机加上参数-n或者是--just-print ，执行时只显示所要执行的命令，但不会真正的执行这个命令。只有在这种情况下 make 才会打印出所有的 make 需要执行的命令，其中包括了使用的“@”字符开始的命令。这个选项对于我们调试 Makefile 非常的有用，使用这个选项就可以按执行顺序打印出 Makefile 中所需要执行的所有命令。而 make 参数-s或者是--slient则是禁止所有的执行命令的显示。就好像所有的命令行都使用“@”开始一样。

当规则中的目标需要被重建的时候，此规则所定义的命令将会被执行，如果是多行的命令，那么每一行命令将是在一个独立的子 shell 进程中被执行。因此，多命令行之间的执行命令时是相互独立的，相互之间不存在依赖。

在 Makefile 中书写在同一行中的多个命令属于一个完整的 shell 命令行，书写在独立行的一条命令是一个独立的 shell 命令行。因此：在一个规则的命令中命令行 “cd”改变目录不会对其后面的命令的执行产生影响。就是说之后的命令执行的工作目录不会是之前使用“cd”进入的那个目录。如果达到这个目的，就不能把“cd”和其后面的命令放在两行来书写。而应该把这两个命令放在一行上用分号隔开。这样才是一个完整的 shell 命令行。

如果想把一个完整的shell命令行书写在多行上，需要使用反斜杠 ()来对处于多行的命令进行连接，表示他们是一个完整的shell命令行。例如上例我们也可以这样书写：

make 对所有规则的命令的解析使用环境变量“SHELL”所指定的那个程序。在 GNU make 中，默认的程序时 “/bin/sh”。不像其他的绝大多数变量，他们的只可以直接从同名的系统环境变量那里获得。make 的环境变量 “SHELL”没有使用环境变量的定义。因为系统环境变量“SHELL”指定的那个程序被用来作为用户和系统交互的接口程序，他对于不存在直接交互过程的 make 显然不合适。在 make 环境变量中“SHELL”会被重新赋值；他作为一个变量我们也可以在 Makefile 中明确的给它赋值，变量“SHELL“的默认值时“/bin/sh”。

GNU make 支持同时执行多条命令。通常情况下，同一时刻只有一个命令在执行，下一个命令只有在当前命令结束之后才能够开始执行。不过可以通过 make 命令行选项 "-j" 或者 "--jobs" 来告诉 make 在同一时刻可以允许多条命令同时执行。

如果选项 "-j" 之后存在一个整数，其含义是告诉 make 在同一时刻可以允许同时执行的命令行的数目。这个数字被称为job slots。当 "-j" 选项中没有出现数字的时候，那么同一时间执行的命令数目没有要求。使用默认的job solts，值为1，表示make将串行的执行规则的命令（同一时刻只能由一条命令被执行）。

并行执行命令所带来的问题是显而易见的：

• 多个同时执行的命令的输出信息将同时被输出到终端。当出现错误时很难根据一大堆凌乱的信息来区分那条命令执行错误。

• 在同一时刻可能会存在多个命令执行的进程同时读取到标准输入，但是对于白哦准输入设备来说，在同一时刻只能存在一个进程访问它。就是说在某个时间点，make只能保证此刻正在执行的进程中的一个进程读取标准输入流。而其他的进程键的标准输入流将设置为无效。因此在此一时刻多个执行命令的进程中只有一个进程获得标准输入，而其他的需要读取标准输入流的进程由于输入流无效而导致致命的错误。

包含其他文件使用的关键字是 "include"，和 C 语言包含头文件的方式相同。

filenames 是 shell 支持的文件名（可以使用通配符表示的文件）。注意："include" 关键字所在的行首可以包含一个或者是多个的空格（读取的时候空格会被自动的忽略），但是不能使用 Tab 开始，否则会把 "include" 当作式命令来处理。包含的多个文件之间要使用空格分隔开。使用 "include" 包含进来的 Makefile 文件中，如果存在函数或者是变量的引用，它们会在包含的 Makefile 中展开。

include 通常使用在以下的场合：

• 在一个工程文件中，每一个模块都有一个独立的 Makefile 来描述它的重建规则。它们需要定义一组通用的变量定义或者是模式规则。通用的做法是将这些共同使用的变量或者模式规则定义在一个文件中，需要的时候用 "include" 包含这个文件。

• 当根据源文件自动产生依赖文件时，我们可以将自动产生的依赖关系保存在另一个文件中。然后在 Makefile 中包含这个文件。

注意：如果使用 "include" 包含文件的时候，指定的文件不是文件的绝对路径或者是为当前文件下没有这个文件，make 会根据文件名会在以下几个路径中去找，首先我们在执行 make 命令的时候可以加入选项 "-I" 或 "--include-dir"

如果在上面的路径没有找到 "include" 指定的文件，make 将会提示一个文件没有找到的警示提示，但是不会退出，而是继续执行 Makefile 的后续的内容。当完成读取整个 Makefile 后，make 将试图使用规则来创建通过 "include" 指定但不存在的文件。当不能创建的时候，文件将会保存退出。

使用方法和 "include" 的使用方法相同。

这两种方式之间的区别：

• 使用 "include <filenames>" ，make 在处理程序的时候，文件列表中的任意一个文件不存在的时候或者是没有规则去创建这个文件的时候，make 程序将会提示错误并保存退出。

• 使用 "-include <filenames>"，当包含的文件不存在或者是没有规则去创建它的时候，make 将会继续执行程序，只有真正由于不能完成终极目标重建的时候我们的程序才会提示错误保存退出。

我们都知道在一个大的工程文件中，不同的文件按照功能被划分到不同的模块中，也就说很多的源文件被放置在了不同的目录下。每个模块可能都会有自己的编译顺序和规则，如果在一个 Makefile 文件中描述所有模块的编译规则，就会很乱，执行时也会不方便，所以就需要在不同的模块中分别对它们的规则进行描述，也就是每一个模块都编写一个 Makefile 文件，这样不仅方便管理，而且可以迅速发现模块中的问题。这样我们只需要控制其他模块中的 Makefile 就可以实现总体的控制，这就是 make 的嵌套执行。

如何来使用呢？举例说明如下：

这个例子可以这样来理解，在当前目录下有一个目录文件 subdir 和一个 Makefile 文件，子目录 subdir 文件下还有一个 Makefile 文件，这个文件是用来描述这个子目录文件的编译规则。使用时只需要在最外层的目录中执行 make 命令，当命令执行到上述的规则时，程序会进入到子目录中执行 make。这就是嵌套执行 make，我们把最外层的 Makefile 称为是总控

上述的规则也可以换成另外一种写法：

在 make 的嵌套执行中，我们需要了解一个变量 "CURDIR"，此变量代表 make 的工作目录。当使用 make 的选项 "-C" 的时候，命令就会进入指定的目录中，然后此变量就会被重新赋值。总之，如果在 Makefile 中没有对此变量进行显式的赋值操作，那么它就表示 make 的工作目录。我们也可以在 Makefile 中为这个变量赋一个新的值，当然重新赋值后这个变量将不再代表 make 的工作目录。

使用 make 嵌套执行的时候，变量是否传递也是我们需要注意的。如果需要变量的传递，那么可以这样来使用：export <variable>

<variable>是变量的名字，不需要使用 "$" 这个字符。如果所有的变量都需要传递，那么只需要使用 "export" 就可以，不需要添加变量的名字。

make 命令传递的参数，并且会传递到下层的 Makefile 中，这是一个系统级别的环境变量。

案例：通过一个大的项目工程来详细的分析一下如何嵌套执行 make。

假设有一个 MP3 player 的应用程序，它可以被划分为若干个组件：用户界面（ui）、编解码器（codec）以及数据管理库（db）。它们分别可以用三个程序库来表示：libui.a、libcodec.a 和 libdb.a。将这些组件紧凑的放到一起就可以组成这个应用程序。具体的文件结构展示为（我们展示的只是目录文件，没有展示详细的源文件）:

├──include //编译的时候需要链接的库文件

├──lib //源文件所在的目录，子目录文件中包含Makefile文件

│ ├──codec //编解码器所在的源文件的目录

│ ├──db //数据库源文件所在的目录

│ ├──ui //用户界面源文件所在目录

└──doc //这个工程编译说明

我们可以看到最外层有一个 Makefile 文件，这就是我们的 "总控Makefile" 文件，我们使用这个 Makefile 调用项目中各个子目录的 Makefile 文件的运行。假设只有我们的 lib 目录下和 app 目录下的各个子目录含有 Makefile 文件。那我们总控的 Makefile 的文件可以这样来写：

我们可以看到在 "总控 Makefile" 中，一个规则在工作目标上列出了所有的子目录，它对每一个子目录的 Makefile 调用的代码是：(libraries) :

在 Makefile 文件中，MAKE 变量应该总是用来调用 make 程序。make 程序一看到 MAKE 变量就会把它设成 make 的实际路径，所以递归调用中的每次调用都会使用同一个执行文件。此外，当命令 --touch(-t)、--just-print(-n) 和 --question(-q) 被使用时，包含 MAKE 变量的每一行都会受到特别的处理。

由于这些“工作目标目录”被设成 .PHONY 的依赖文件，所以即使工作目标已经更新，此规则仍旧会进行更新动作。使 --directory(-C) 选项的目的是要让 make 在读取 Makefile 之前先切换到相应的 "工作目录" 。

当 make 在建立依存图的时候找不到程序库与 app/player 工作目标之间的依存关系时，这意味着建立任何程序库之前，make 将会先执行 app/player 目录中的 Makefile。显然这将会导致失败的结果，因为应用程序的链接需要程序库。为解决这个问题，我们会提供额外的依存信息：

我们在此处做了如下的描述：运行 app/player 目录中的 Makefile 之前必须先运行程序库子目录中的 Makefile。此外，编译 lib/ui 目录中的程序代码之前必须先编译 lib/db 和lib/codec 目录中的程序库。这么做可以确保任何自动产生的程序代码，在 lib/ui 目录中的程序代码被编译之前就已经产生出来了。

更新必要条件的时候，会引发微妙的次序问题。如同所有的依存关系，更新的次序取决于依存图的分析结果，但是当工作目标的必要条件（依赖文件）出现在同一行时，GNU make 将会从左至右的次序进行更新。例如：

如果不存在其他的依存关系，这6个必要条件的更新动作可以是任何次序，不过GNU make将会以从左向右的次序来更新出现在同一行的必要条件，这会产生如下的更新次序："a b c d e f" 或 "d e f a b c"。注意：不要因为之前这么做更新的次序是对的，就以为每次这么做都是对的，而忘了提供完整的依存信息。

最后，依存分析可能会产生不同的次序而引发一些问题。所以，如果有一组工作目标需要以特定的次序进行更新时，就必须提供适当的必要条件来实现正确的次序。

当我们在最外层执行 make 的时候我们会看到l输出的信息：

变量的值加上方括号之后被一起输出。在这个简单的例子里，每个组件的 Makefile 只会输出组件正在更新的信息，而不会真正的更新组件。

我们通过这个例子应该可以了解，在 make 的嵌套执行执行的时候的调用子目录的方式，还有子目录再去执行 make 时候的顺序。这是一个很典型的例子，我们的每一个工程文件都可以用上面的结构展示出来，我们只要懂得每一个子目录在被调用时候的顺序，我们就可以很轻松的编写 "总控Makefile" 。

make命令参数和选项大汇总

我们在在执行 make 命令时，有的时候需要加上一下参数选项来保证我们的程序的执行，其实之前已经遇到过 make 在执行命令的时候需要添加上参数选项，比如只打印命令但不执行使用的参数是 "-n" ，还有只执命令不打印命令的参数选项是 "-s"，包含其它文件的路径参数选项是 "-include"等等。

我们现在列举一下 make 可以使用的参数选项，以及它们的功能是什么。

模式规则中的目标。规则中的目标形式是多种多样的，它可以是一个或多个的文件、可以是一个伪目标，这是我们之前讲到过的，也是经常使用的。其实规则目标还可以是其他的类型，下面是对这些类型的详细的说明。

如果一个目标中没有命令或者是依赖，并且它的目标不是一个存在的文件名，在执行此规则时，目标总会被认为是最新的。就是说：这个规则一旦被执行，make 就认为它的目标已经被更新过。这样的目标在作为一个规则的依赖时，因为依赖总被认为更新过，因此作为依赖在的规则中定义的命令总会被执行。看一个例子：

这个例子中，目标 "FORCE" 符合上边的条件。它作为目标 "clean" 的依赖，在执行 make 的时候，总被认为更新过。因此 "clean" 所在的规则而在被执行其所定义的那个命令总会被执行。这样的一个目标通常我们将其命名为 "FORCE"。

例子中使用 "FORCE" 目标的效果和将 "clean" 声明为伪目标的效果相同。

空目标文件是伪目标的一个变种，此目标所在的规则执行的目的和伪目标相同——通过 make 命令行指定将其作为终极目标来执行此规则所定义的命令。和伪目标不同的是：这个目标可以是一个存在的文件，但文件的具体内容我们并不关心，通常此文件是一个空文件。

空目标文件只是用来记录上一次执行的此规则的命令的时间。在这样的规则中，命令部分都会使用 "touch" 在完成所有的命令之后来更新目标文件的时间戳，记录此规则命令的最后执行时间。make 时通过命令行将此目标作为终极目标，当前目标下如果不存在这个文件，"touch" 会在第一次执行时创建一个的文件。

通常，一个空目标文件应该存在一个或者多个依赖文件。将这个目标作为终极目标，在它所依赖的文件比它更新时，此目标所在的规则的命令行将被执行。就是说如果空目标文件的依赖文件被改变之后，空目标文件所在的规则中定义的命令会被执行。看一个例子：

| .PHONY: | 这个目标的所有依赖被作为伪目标。伪目标是这样一个目标：当使用 make 命令行指定此目标时，这个目标所在的规则定义的命令、无论目标文件是否存在都会被无条件执行。 |
| .SUFFIXES: | 这个目标的所有依赖指出了一系列在后缀规则中需要检查的后缀名 |
| .DEFAULT: | Makefile 中，这个特殊目标所在规则定义的命令，被用在重建那些没有具体规则的目标，就是说一个文件作为某个规则的依赖，却不是另外一个规则的目标时，make 程序无法找到重建此文件的规则，这种情况就执行 ".DEFAULT" 所指定的命令。 |
| .PRECIOUS: | 这个特殊目标所在的依赖文件在 make 的过程中会被特殊处理：当命令执行的过程中断时，make 不会删除它们。而且如果目标的依赖文件是中间过程文件，同样这些文件不会被删除。 |
| .INTERMEDIATE: | 这个特殊目标的依赖文件在 make 执行时被作为中间文件对待。没有任何依赖文件的这个目标没有意义。 |
| .SECONDARY: | 这个特殊目标的依赖文件被作为中过程的文件对待。但是这些文件不会被删除。这个目标没有任何依赖文件的含义是：将所有的文件视为中间文件。 |
| .IGNORE | 这个目标的依赖文件忽略创建这个文件所执行命令的错误，给此目标指定命令是没有意义的。当此目标没有依赖文件时，将忽略所有命令执行的错误。 |
| .LOW_RESOLUTION_TIME: | 这个目标的依赖文件被 make 认为是低分辨率时间戳文件，给这个目标指定命令是没有意义的。通常的目标都是高分辨率时间戳。 |
| .SILENT: | 出现在此目标 ".SILENT" 的依赖文件列表中的文件，make 在创建这些文件时，不打印出此文件所执行的命令。同样，给目标 "SILENT" 指定命令行是没有意义的。 |
| .EXPORT_ALL_VARIABLES: | 此目标应该作为一个简单的没有依赖的目标，它的功能是将之后的所有变量传递给子 make 进程。 |
| .NOTPARALLEL: | Makefile 中如果出现这个特殊目标，则所有的命令按照串行的方式执行，即使是存在 make 的命令行参数 "-j" 。但在递归调用的子make进程中，命令行可以并行执行。此目标不应该有依赖文件，所有出现的依赖文件将会被忽略。 |</byte-sheet-html-origin>

Makefile 中，一个文件可以作为多个规则的目标。这种情况时，以这个文件为目标的规则的所有依赖文件将会被合并成此目标一个依赖文件列表，当其中的任何一个依赖文件比目标更新时，make 将会执行特定的命令来重建这个目标。

对于一个多规则的目标，重建这个目标的命令只能出现在一个规则中。如果多个规则同时给出重建此目标的命令，make 将使用最后一个规则中所定义的命令，同时提示错误信息。某些情况，需要对相同的目标使用不同的规则中所定义的命令，我们需要使用另一种方式——双冒号规则来实现。

一个仅仅描述依赖关系的描述规则可以用来给出一个或者时多个目标文件的依赖文件。例如，Makefile 中通常存在一个变量，就像我们以前提到的 "objects" ,它定义为所有的需要编译的生成 .o 文件的列表。这些 .o 文件在其源文件中包含的头文件 "config.h" 发生变化之后能够自动的被重建，我们可以使用多目标的方式来书写 Makefile：

这样做的好处是：我们可以在源文件增加或者删除了包含的头文件以后不用修改已存在的 Makefile 的规则，只需要增加或者删除某一个 .o 文件依赖的头文件。这种方式很简单也很方便。

我们也可以通过一个变量来增加目标的依赖文件，使用 make 的命令行来指定某一个目标的依赖头文件，例如：

它的意思是：如果我们执 "make exteradeps=foo.h" 那么 "foo.h" 将作为所有的 .o 文件的依赖文件。当然如果只执行 "make" 的话，就没有指定任何文件作为 .o 文件的依赖文件。

我们定义变量的目的是为了简化我们的书写格式，代替我们在代码中频繁出现且冗杂的部分。它可以出现在我们规则的目标中，也可以是我们规则的依赖中。我们使用的时候会经常的对它的值（表示的字符串）进行操作。遇到这样的问题我们可能会想到我们的字符串操作函数，比如 "patsubst" 就是我们经常使用的。但是我们使用变量同样可以解决这样的问题，我们通过下面的例子来具体的分析一下。

这段代码实现的功能是字符串的后缀名的替换，把变量 foo 中所有的以 .c 结尾的字符串全部替换成 .o 结尾的字符串。我们在 Makefile 中这样写，然后再 shell 命令行执行 make 命令，就可以看到打印出来的是 "a.o b.o d.o" ，实现了文件名后缀的替换。注意：括号中的变量使用的是变量名而不是变量名的引用，变量名的后面要使用冒号和参数选项分开，表达式中间不能使用空格。第二个变量 obj 是对整体的引用。

上面的例子我们可以换一种更加通用的方式来写，代码展示如下：

我们在 shell 中执行 make 命令，发现结果是相同的。

对比上面的实例我们可以看到，表达式中使用了 "%" 这个字符，这个字符的含义就是自动匹配一个或多个字符。在开发的过程中，我们通常会使用这种方式来进行变量替换引用的操作。

为什么这种方式比第一种方式更加实用呢？我们在实际使用的过程中，我们对变量值的操作不只是修改其中的一个部分，甚至是改变其中的多个，那么第一种方式就不能实现了。我们来看一下这种情况：

我们可以看到这个例子中我们操作的是两个不连续的部分，我们执行 make 后打印的值是 "x123y x1234y x12345y"，这种情况下我们使用第一种情况就不能实现，所以第二种的使用更全面。

变量的嵌套引用的具体含义是这样的，我们可以在一个变量的赋值中引用其他的变量，并且引用变量的数量和和次数是不限制的。下面我们通过几个实例来说明一下。

这种用法是最常见的使用方法，打印出 var 的值就是 test。我们可以认为是一层的嵌套引用。

我们再去执行 make 命令的时候得到的结果也是 test，我们可以来分析一下这段代码执行的过程：$(foo) 代表的字符串是 bar，我们也定义了变量 bar，所以我们可以对 bar 进行引用，变量 bar 表示的值是 test，所以对 bar 的引用就是 test，所以最终 var 的值就是 test。这是变量的二层嵌套执行，当然我们还可以使用三层的嵌套执行，写法跟上面的方式是一样的。嵌套的层数也可以更多，但是不提倡使用。

我们再去使用变量的时候，我们并不是只能引用一个变量，可以有多个变量的引用，还可以包含很多的变量还可以是一些文本字符。我们可以通过一些例子来说明一下。

在命令行执行 make 我们可以得到 var 的值是 hello。这是变量嵌套引用的时候可以包含其它字符的使用情况。

这个实例跟上面实例的运行结果是一样的。我们可以看到这个实例中使用了两个变量的引用还有其它的字符。

变量的嵌套引用和我们的变量的递归赋值的区别：嵌套引用的使用方法就是用一个变量表示另外一个变量，然后进行多层的引用。而递归展开的变量表示当一个变量存在对其它变量的引用时，对这变量替换的方式。递归展开在另外一个角度描述了这个变量在定义是赋予它的一个属性或者风格。并且我们可以在定义个一个递归展开式的变量时使用套嵌引用的方式，但是建议你的实际编写 Makefile 时要尽量避免这种复杂的用法。

在实际使用的过程中变量的第一种用法经常使用的，第二种用法我们很少使用，应该说是尽量避免使用变量的嵌套引用。在必须要使用的时候我们应该做到嵌套的层数是越少越好的。因为使用这种方法表达会比较的复杂，如果条理不清楚的话我们就会出错。并且在给其他人看的时候也会不容易理解。

Makefile 中提供了两个控制 make 运行方式的函数。其作用是当 make 执行过程中检测到某些错误时为用户提供消息，并且可以控制 make 执行过程是否继续。这两个函数是 "error" 和 "warning"，我们来详细的介绍一下这两个函数。

• 函数功能：产生致命错误，并提示 "TEXT..." 信息给用户，并退出 make 的执行。需要说明的是："error" 函数是在函数展开时（函数被调用时）才提示信息并结束 make 进程。因此如果函数出现在命令中或者一个递归的变量定义时，读取 Makefile 时不会出现错误。而只有包含 "error" 函数引用的命令被执行，或者定义中引用此函数的递归变量被展开时，才会提示知名信息 "TEXT..." 同时退出 make。

• 函数说明："error" 函数一般不出现在直接展开式的变量定义中，否则在 make 读取 Makefile 时将会提示致命错误。

我们通过两个例子来说明一下；

这个例子，在 make 读取 Makefile 时不会出现致命错误。只有目标 "err" 被作为是一个目标被执行时才会出现。

• 函数功能：函数 "warning" 类似于函数 "error" ，区别在于它不会导致致命错误（make不退出），而只是提示 "TEXT..."，make 的执行过程继续。

• 函数说明：用法和 "error" 类似，展开过程相同。

make 执行过程的致命错误都带有前缀字符串 "***"。错误信息都有前缀，一种是执行程序名作为错误前缀（通常是 "make"）；另外一种是当 Makefile 本身存在语法错误无法被 make 解析并执行时，前缀包含了 Makefile 文件名和出现错误的行号。

在下述的错误列表中，省略了普通前缀：

这类错误并不是 make 的真正错误。它表示 make 检测到 make 所调用的作为执行命令的程序返回一个非零状态（Error NN），或者此命令程序以非正常方式退出（携带某种信号）。

如果错误信息中没有附加 "***" 字符串，则是子过程的调用失败，如果 Makefile 中此命令有前缀 "-"，make 会忽略这个错误。

错误的原因：不可识别的命令行，make 在读取 Makefile 过程中不能解析其中包含的内容。GNU make在读取 Makefile 时根据各种分隔符（:, =, [TAB]字符等）来识别 Makefile 的每一行内容。这些错误意味着 make 不能发现一个合法的分隔符。

出现这些错误信息的可能的原因是（或许是编辑器，绝大部分是ms- windows的编辑器）在 Makefile 中的命令之前使用了4个（或者8个）空格代替了 [Tab] 字符。这种情况，将产生上述的第二种形式产生错误信息。且记，所有的命令行都应该是以 [Tab] 字符开始的。

Makefile 可能是以命令行开始：以 [Tab] 字符开始，但不是一个合法的命令行（例如，一个变量的赋值）。命令行必须和规则一一对应。

产生第二种的错误的原因可能是一行的第一个非空字符为分号，make 会认为此处遗漏了规则的 "target: prerequisite" 部分。

无法为重建目标“XXX”找到合适的规则，包括明确规则和隐含规则。

修正这个错误的方法是：在 Makefile 中添加一个重建目标的规则。其它可能导致这些错误的原因是 Makefile 中文件名拼写错误，或者破坏了源文件树（一个文件不能被重建，可能是由于依赖文件的问题）。

第一个错误表示在命令行中没有指定需要重建的目标，并且 make 不能读入任何 Makefile 文件。第二个错误表示能够找到 Makefile 文件，但没有终极目标或者没有在命令行中指出需要重建的目标。这种情况下，make 什么也不做。

对同一目标 "XXX" 存在一个以上的重建命令。GNU make 规定：当同一个文件作为多个规则的目标时，只能有一个规则定义重建它的命令（双冒号规则除外）。如果为一个目标多次指定了相同或者不同的命令，就会产生第一个告警；第二个告警信息说新指定的命令覆盖了上一次指定的命令。

make 的变量 "XXX"（递归展开式）在替换展开时，引用它自身。无论对于直接展开式变量（通过:=定义的）或追加定义（+=），这都是不允许的。

变量或者函数引用语法不正确，没有使用完整的的括号（缺少左括号或者右括号）。

函数 "XXX" 引用时参数数目不正确。函数缺少参数。

不正确的静态模式规则。

第一条错误的原因是：静态模式规则的目标段中没有模式目标；

第二条错误的原因是：静态模式规则的目标段中存在多个模式目标；

第三条错误的原因是：静态模式规则的目标段目标模式中没有包含模式字符“%”；

第四条错误的原因是：静态模式规则的三部分都包含了模式字符“%”。正确的应该是只有后两个才可以包含模式字符“%”。

这一条告警和下条告警信息发生在：make 检测到递归的 make 调用时，可通信的子 make 进程出现并行处理的错误。递归执行的 make 的命令行参数中存在 "-jN" 参数（N的值大于1），在有些情况下可能导致此错误，例如：Makefile 中变量 "MAKE" 被赋值为 "make –j2"，并且递归调用的命令行中使用变量 "MAKE"。在这种情况下，被调用 make

为了现实 make 进程之间的通信，上层 make 进程将传递信息给子 make 进程。在传递信息过程中可能存在这种情况，子 make 进程不是一个实际的 make 进程，而上层make却不能确定子进程是否是真实的 make 进程。它只是将所有信息传递下去。上层 make 采用正常的算法来决定这些。当出现这种情况，子进程只会接受父进程传递的部分有用的信息。子进程会产生该警告信息，之后按照其内建的顺序方式进行处理。