Makefile 从入门到工程实践：Linux C 自动编译与 VPATH 组织

Make 简介

• 工程管理器，顾名思义，是指管理较多的文件
• Make 工程管理器也就是个“自动编译管理器”，这里的“自动”是指它能够根据文件时间戳自动发现更新过的文件而减少编译的工作量，同时，它通过读入 Makefile 文件的内容来执行大量的编译工作
• Make 将只编译改动的代码文件，而不用完全编译。

会不会写 Makefile，从一个侧面说明了一个人是否具备完成大型工程的能力，Makefile 关系到了整个工程的编译规则。

一个工程中的源文件不计其数，它们按类型、功能、模块分别放在若干个目录中，Makefile 定义了一系列规则来指定：哪些文件需要先编译、哪些文件需要后编译、哪些文件需要重新编译，甚至还能执行更复杂的操作。因为 Makefile 就像一个 Shell 脚本一样，其中也可以执行操作系统的命令。

Makefile 带来的好处就是“自动化编译”——一旦写好，只需要一个 make 命令，整个工程完全自动编译，极大地提高了软件开发的效率。

Makefile 基本结构

• Makefile 是 Make 读入的唯一配置文件
  • 由 make 工具创建的目标体（target），通常是目标文件或可执行文件
  • 要创建的目标体所依赖的文件（dependency_file）
  • 创建每个目标体时需要运行的命令（command）

注意：命令行前面必须是一个 TAB 键，否则编译错误为：*** missing separator. Stop.

例如：

Makefile 格式：

target : dependcy_files    
<TAB>command

target 也就是一个目标文件，可以是 Object File，也可以是执行文件，还可以是一个标签（Label）。

dependcy_files 就是生成该 target 所需要的文件或是目标。

command 也就是 make 需要执行的命令，可以是任意的 Shell 命令。

这是一个文件的依赖关系：target 这一个或多个目标文件依赖于 dependcy_files 中的文件，其生成规则定义在 command 中。换句话说，如果 dependcy_files 中有一个以上的文件比 target 文件要新，command 所定义的命令就会被执行。这就是 Makefile 的规则，也是 Makefile 中最核心的内容。

注意：在看别人写的 Makefile 文件时，你可能会碰到以下三个变量：$@、$^、$<，它们代表的意义分别是：

$@：目标文件，$^：所有的依赖文件，$<：第一个依赖文件。

这个变量的问题，我们在下面继续讲解。

复杂一些的例子：

sunq:kang.o yul.o
 gcc kang.o yul.o -o sunq
kang.o:kang.c kang.h
 gcc -Wall -O -g-c kang.c -o kang.o
yul.o:yul.c yul.h
 gcc -Wall -O -g-c yul.c -o yul.o
clean:
     rm *.o test

注释：

-Wall：表示允许发出 gcc 所有有用的报警信息。

-c：只是编译不连接，生成目标文件 .o

-o file：表示把输出文件输出到 file 里

我们可以把这个内容保存在文件名为 “Makefile” 或 “makefile” 的文件中，然后在该目录下直接输入命令 make 就可以生成执行文件 sunq。

如果要删除执行文件和所有的中间目标文件，那么，只要简单地执行一下 make clean 就可以了。

在这个 Makefile 中，目标文件（target）包含：执行文件 sunq 和中间目标文件（*.o），依赖文件（prerequisites）就是冒号后面的那些 .c 文件和 .h 文件。每一个 .o 文件都有一组依赖文件，而这些 .o 文件又是执行文件 sunq 的依赖文件。

依赖关系的实质就是说明目标文件是由哪些文件生成的，换言之，目标文件是哪些文件更新的。

在定义好依赖关系后，后续的那一行定义了如何生成目标文件的操作系统命令，一定要以一个 Tab 键作为开头。记住，make 并不管命令是怎么工作的，它只管执行所定义的命令。

make 会比较 targets 文件和 dependcy_files 文件的修改日期，如果 dependcy_files 文件的日期要比 targets 文件的日期要新，或者 target 不存在，那么 make 就会执行后续定义的命令。

make 是如何工作的

大多数 make 都支持 “makefile” 和 “Makefile” 这两种默认文件名。你也可以使用别的文件名来书写 Makefile，比如：“Make.Linux”“Make.Solaris”“Make.AIX” 等。如果要指定特定的 Makefile，可以使用 make 的 -f 和 --file 参数，例如：make -f Make.Linux 或 make --file Make.AIX。

在默认方式下，也就是我们只输入 make 命令时：

1. make 会在当前目录下找名字叫 “Makefile” 或 “makefile” 的文件。
2. 如果找到，它会找文件中的第一个目标文件（target），在上面的例子中，它会找到 “sunq” 这个文件，并把这个文件作为最终的目标文件。
3. 如果 sunq 文件不存在，或是 sunq 所依赖的后面 .o 文件的文件修改时间要比 sunq 这个文件新，那么，它就会执行后面所定义的命令来生成 sunq 这个文件。
4. 如果 sunq 所依赖的 .o 文件不存在，那么 make 会在当前文件中找目标为 .o 文件的依赖性，如果找到则再根据那一个规则生成 .o 文件。这有点像一个堆栈的过程。
5. 当然，你的 C 文件和 H 文件是存在的，于是 make 会生成 .o 文件，然后再用 .o 文件完成 make 的终极任务，也就是执行文件 sunq。

这就是整个 make 的依赖性，make 会一层又一层地去找文件的依赖关系，直到最终编译出第一个目标文件。

在找寻的过程中，如果出现错误，比如最后被依赖的文件找不到，那么 make 就会直接退出并报错；而对于所定义的命令的错误，或是编译不成功，make 根本不理。

make 只管文件的依赖性，即如果它找完依赖关系之后，冒号后面的文件还是不在，那么对不起，它就不工作了。

make 工作时的执行步骤如下：

1. 读入所有的 Makefile。
2. 读入被 include 的其它 Makefile。
3. 初始化文件中的变量。
4. 推导隐晦规则，并分析所有规则。
5. 为所有的目标文件创建依赖关系链。
6. 根据依赖关系，决定哪些目标要重新生成。
7. 执行生成命令。

第 1-5 步为第一个阶段，第 6-7 步为第二个阶段。在第一个阶段中，如果定义的变量被使用了，make 会把其展开在使用的位置。

但 make 并不会完全马上展开，make 使用的是拖延战术：如果变量出现在依赖关系的规则中，那么仅当这条依赖被决定要使用了，变量才会在其内部展开。

Makefile 文件中的依赖关系理解

假设当前工程目录为 object/，该目录下有 6 个文件，分别是：main.c、abc.c、xyz.c、abc.h、xyz.h 和 Makefile。

其中 main.c 包含头文件 abc.h 和 xyz.h，abc.c 包含头文件 abc.h，xyz.c 包含头文件 xyz.h，而 abc.h 又包含了 xyz.h。它们的依赖关系如图。

Makefile 应该写成这个样子（假设生成目标 main）：

main:main.o abc.o xyz.o
     gcc main.o abc.o xyz.o -o main
main.o:main.c abc.h xyz.h
     gcc -c main.c –o main.o -g
abc.o:abc.c abc.h xyz.h
     gcc -c abc.c –o abc.o -g
 xyz.o:xyz.c xyz.h
     gcc -c xyz.c -o xyz.o -g
.PHONY:clean
 clean:
   rm main main.o abc.o xyz.o -f

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 文件。

Makefile 基础使用：一个多文件 C 工程实例

接下来我们做个实例，学习一下怎么写 Makefile。

写两个 C 程序：

写一个 head.h 头文件，用来声明上面的函数：

写一个 main 程序：

如果一直用这样的方式写，一旦改动其中某个文件，文件数量一多，就会非常麻烦。

所以 Makefile 的使用会带来很大的惊喜。

test:fun1.o fun2.o main.o
        gcc fun1.o fun2.o main.o -o test
fun2.o:fun2.c
        gcc -c -Wall fun2.c -o fun2.o
fun1.o:fun1.c
        gcc -c -Wall fun1.c -o fun1.o
main.o:main.c
        gcc -c -Wall main.c -o main.o

Makefile 内部流程：

若我要改动其中的 C 文件，例如改动 fun2.c：

改动好后，再执行 make，会发现只有 fun2.c 被重新生成为 fun2.o；因为 fun2.o 是新生成的，所以也要重新生成 test。

结果：

执行 Makefile 后，文件夹内会生成很多中间文件：

我们需要清理时，往往通过 make 相关命令来清理，而不是用 rm 一个一个删除。

clean:
     rm *.o test

使用 make + 目标名：

这样中间文件就都被清理了：

伪目标：肯定会被执行的文件。如果重名了：

重名后，发现 clean 不工作了。make 默认它没被改动，所以不会执行。如何避免这个问题呢？

在 Makefile 中加 .PHONY: clean。

.PHONY 的作用是隐含说明 clean 是个伪目标文件。

.PHONY:clean

这样就不会被重名耽误运行了：

清空目标文件的规则：每个 Makefile 中都应该写一个清空目标文件（.o 和执行文件）的规则，这不仅便于重编译，也很利于保持文件清洁。一般的风格都是：

clean:
      rm edit $(objects)

更为稳健的做法是：

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

前面说过，.PHONY 表示 clean 是一个“伪目标”。

而在 rm 命令前面加了一个小减号的意思就是：也许某些文件出现问题，但不要管，继续做后面的事。

当然，clean 的规则不要放在文件的开头，不然，它就会变成 make 的默认目标。不成文的规矩是——“clean 从来都是放在文件的最后”。

创建和使用变量

为了 Makefile 的易维护，在 Makefile 中我们可以使用变量。Makefile 的变量也就是一个字符串，理解成 C语言 中的宏可能会更好。

上面的 Makefile 例子：

test:fun1.o fun2.o main.o
        gcc fun1.o fun2.o main.o -o test
fun2.o:fun2.c
        gcc -c -Wall fun2.c -o fun2.o
fun1.o:fun1.c
        gcc -c -Wall fun1.c -o fun1.o
main.o:main.c
        gcc -c -Wall main.c -o main.o
.PHONY:clean
clean
 rm *.o test

比如，我们声明一个变量，叫 objects，用来表示 obj 文件。我们在 Makefile 一开始就这样定义：

 objects = fun1.o fun2.o main.o

于是，我们就可以很方便地在 Makefile 中以 $(objects) 的方式来使用这个变量了。改良版 Makefile 就变成下面这个样子：

objects = fun1.o fun2.o main.o
test:$(objects)
        gcc fun1.o fun2.o main.o -o test
fun2.o:fun2.c
        gcc -c -Wall fun2.c -o fun2.o
fun1.o:fun1.c
        gcc -c -Wall fun1.c -o fun1.o
main.o:main.c
        gcc -c -Wall main.c -o main.
.PHONY:clean
clean
 rm *.o test

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

简单总结一下：

变量定义的目的与方式

创建变量的目的：

用来代替一个文本字符串：

• 系列文件的名字
• 传递给编译器的参数
• 需要运行的程序
• 需要查找源代码的目录
• 你需要输出信息的目录
• 你想做的其它事情

如何定义变量：

• 递归展开方式：VAR=var
• 简单方式：VAR:=var
• 变量使用：$(VAR)
• 用 $ 来表示
• 类似于编程语言中的宏

再举一个例子：

sunq:kang.o yul.o
 gcc kang.o yul.o -o sunq
kang.o:kang.c kang.h
 gcc -Wall -O -g-c kang.c -o kang.o
yul.o:yul.c yul.h
 gcc -Wall -O -g-c yul.c -o yul.o
.PHONY:clean
clean
 rm *.o test

用变量来替换：

OBJS = kang.o yul .o
CC = gcc
CFLAGS = -Wall -O -g

sunq : $(OBJS)
 $(CC)$(OBJS) -o sunq
kang.o : kang.c kang.h
 $(CC)$(CFLAGS)-c kang.c -o kang.o
yul.o : yul.c yul.h
 $(CC)$(CFLAGS)-c yul.c -o yul.o
.PHONY:clean
clean
 rm *.o test

递归展开方式示例：

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

可以通过 $(foo) 来查看。

优点：它可以向后引用变量。

缺点：不能对该变量进行任何扩展，例如 CFLAGS = $(CFLAGS)-O 会造成死循环。

简单方式示例：

m := mm 
x:=$(m) 
y:= $(x) bar
x:=later
echo $(x) $(y)

如：变量 m 的值为 mm，再把 m 的值赋给 x。

这种变量方式更像是 C 语言。

用 ?= 定义变量：

dir :=/foo/bar
FOO?=bar
FOO是？

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

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

为变量添加值

你可以通过 += 为已定义的变量添加新的值：

Main=hello.o hello-1.o 
Main+=hello-2.o

预定义变量和自动变量

预定义变量	含义
AR	库文件维护程序的名称，默认值为 ar。AS 汇编程序的名称默认值为 as。
CC	C 编译器的名称，默认值为 cc。CPP C 预编译器的名称，默认值为 $(CC) -E。
CXX	C++ 编译器的名称，默认值为 g++。
FC	FORTRAN 编译器的名称，默认值为 f77
RM	文件删除程序的名称，默认值为 rm -f

自动变量	含义
$*	不包含扩展名的目标文件名称
$+	所有的依赖文件，以空格分开，并以出现的先后为序，可能包含重复的依赖文件
$<	第一个依赖文件的名称
$?	所有时间戳比目标文件晚的依赖文件，并以空格分开
$@	目标文件的完整名称
$^	所有不重复的目标依赖文件，以空格分开
$%	如果目标是归档成员，则该变量表示目标的归档成员名称

$@：目标文件，$^：所有的依赖文件，$<：第一个依赖文件。这三个变量十分常见且重要。

objects = fun1.o fun2.o main.o
test:$(objects)
        gcc fun1.o fun2.o main.o -o test
fun2.o:fun2.c
        gcc -c -Wall fun2.c -o fun2.o
fun1.o:fun1.c
        gcc -c -Wall fun1.c -o fun1.o
main.o:main.c
        gcc -c -Wall main.c -o main.o
.PHONY:clean
clean
 rm *.o test

变量修改：

objects = fun1.o fun2.o main.o
CFLAGS=-c -Wall

test:$(objects)
        gcc  $(objects) -o test
fun2.o:$<
        gcc $(CFLAGS) fun2.c -o $@
fun1.o:$<
        gcc $(CFLAGS) fun1.c -o $@
main.o:$<
        gcc $(CFLAGS) main.c -o $@
.PHONY:clean
clean
 rm *.o test

环境变量

• make 在启动时会自动读取系统当前已经定义了的环境变量，并且会创建与之具有相同名称和数值的变量。
• 如果用户在 Makefile 中定义了相同名称的变量，那么用户自定义变量将会覆盖同名的环境变量。

直接运行 make 选项

选项	含义
-C dir	读入指定目录下的 Makefile
-f file	读入当前目录下的 file 文件作为 Makefile
-i	忽略所有的命令执行错误
-I dir	指定被包含的 Makefile 所在目录
-n	只打印要执行的命令，但不执行这些命令
-p	显示 make 变量数据库和隐含规则
-s	在执行命令时不显示命令
-w	如果 make 在执行过程中改变目录，打印当前目录名

-C dir：读入指定目录下的 Makefile

make -C Makefile/ 可使用该目录下的 Makefile

-f file：读入当前目录下的 file 文件作为 Makefile

make -f Refuel.debug

make -f Refuel.debug clean

就可以把 Refuel.debug 当作 Makefile 来用。

-i：忽略所有的命令执行错误

假如我们在写代码时，gcc -c -Wall fun2.c  o $@ 写 -o 时忘记了 -。这种时候，我们使用 make -i，它会先把小错误忽略，把代码中能正常执行的先执行，错误的提示出来，但不执行。

-n：只打印要执行的命令，但不执行这些命令

它并不是真的执行命令，而是类似模拟执行。

在 U-Boot 中我们会看到一些内核的 Makefile，如 config.mk 这样的文件中罗列了一些变量的声明：

Makefile 的隐含规则

隐含规则 1：编译 C 程序的隐含规则——让 make 自动推导

make 可以自动推导文件以及文件依赖关系后面的命令，于是我们没必要在每一个 .o 文件后都写上类似的命令。只要 make 看到一个 .o 文件，它就会自动把 .c 文件加在依赖关系中。如果 make 找到一个 whatever.o，那么 whatever.c 就会是 whatever.o 的依赖文件，并且 cc -c whatever.c 也会被推导出来。于是，我们的 Makefile 再也不用写得那么复杂。

objects = fun1.o fun2.o main.o

test:$(objects)
        gcc  $(objects) -o test

fun2.o:fun2.c
fun1.o:fun1.c
main.o:main.c

.PHONY:clean
clean
 rm *.o test

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

总结：<n>.o 的目标的依赖目标会自动推导为 <n>.c，并且其生成命令是 $(CC) -c $(CPPFLAGS) $(CFLAGS)。

隐含规则 2：链接 Object 文件的隐含规则

<n> 目标依赖于 <n>.o，通过运行 C 的编译器来运行链接程序生成（一般是 ld），其生成命令是：$(CC) $(LDFLAGS) <n>.o $(LOADLIBES) $(LDLIBS)。这个规则对于只有一个源文件的工程有效，同时也对多个 Object 文件（由不同的源文件生成）的情况有效。

规则：x : x.o y.o z.o，并且 x.c、y.c、z.c 都存在时，隐含规则将执行如下命令：

cc -c x.c -o x.o

cc -c y.c -o y.o

cc -c z.c -o z.o

cc x.o y.o z.o -o x

如果没有一个源文件（如上例中的 x.c）和你的目标名字（如上例中的 x）相关联，那么你最好写出自己的生成规则，不然，隐含规则会报错。

 fun1 : fun1.o  fun2.o  main.o 

这样就不会报错。

Makefile 总述

Makefile 里主要包含了五个东西：显式规则、隐晦规则、变量定义、文件指示和注释。

1. 显式规则：显式规则说明了如何生成一个或多个目标文件。它由 Makefile 的书写者明确指出：要生成的文件、文件的依赖文件、生成的命令。
2. 隐晦规则：由于 make 有自动推导的功能，所以隐晦规则可以让我们比较简略地书写 Makefile，这是由 make 所支持的。
3. 变量的定义：在 Makefile 中我们要定义一系列的变量，变量一般都是字符串，这一点有点像 C 语言中的宏。当 Makefile 被执行时，其中的变量都会被扩展到相应的引用位置上。
4. 文件指示：包括三个部分：一个是在一个 Makefile 中引用另一个 Makefile，就像 C 语言中的 include 一样；另一个是根据某些情况指定 Makefile 中的有效部分，就像 C 语言中的预编译 #if 一样；还有就是定义一个多行的命令。
5. 注释：Makefile 中只有行注释，和 UNIX 的 Shell 脚本一样，其注释使用 # 字符，这就像 C/C++ 中的 // 一样。如果你要在 Makefile 中使用 # 字符，可以用反斜杠进行转义，如：\#。

VPATH 的用法

Makefile 的 VPATH

VPATH: 虚路径

• 在一些大的工程中，有大量的源文件。我们通常的做法是把这些源文件分类，并存放在不同的目录中。当 make 需要去找寻文件的依赖关系时，你可以在文件前加上路径，但更好的方法是把一个路径告诉 make，让 make 自动去找。
• Makefile 文件中的特殊变量 VPATH 就是完成这个功能的。如果没有指明这个变量，make 只会在当前的目录中去找寻依赖文件和目标文件；如果定义了这个变量，那么 make 就会在当前目录找不到的情况下，到所指定的目录中去找寻文件。
• VPATH = src:../headers
• 上面的定义指定了两个目录：src 和 ../headers，make 会按照这个顺序进行搜索。目录由冒号分隔。当然，当前目录永远是最高优先搜索的地方。

另一个设置文件搜索路径的方法是使用 make 的 vpath 关键字（注意，它是全小写的）。它不是变量，而是 make 的一个关键字。它和上面提到的 VPATH 变量很类似，但更为灵活，可以指定不同的文件在不同的搜索目录中。它有三种使用方法：

1.  vpath <pattern> <directories>     
//为符合模式<pattern>的文件指定搜索目录<directories>。

2.  vpath <pattern>                              
//清除符合模式<pattern>的文件的搜索目录。

3.  vpath                                          
//清除所有已被设置好了的文件搜索目录。

vpath 使用方法中的 <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 目录。

分布在不同路径的程序：如果在不同的目录下写了程序，不用 VPATH 又该如何写 Makefile 呢？

不同目录下我们怎么删除不想要的中间文件呢？

通过指令 find ./ -name "*.o"，可以找到所有 .o 文件。

再输入指令 find ./ -name "*.o" -exec rm {} \;，意思为：把找到的结果拿来交给 rm 去删除。

这样 .o 文件就在不同的目录下删除了：

Makefile 中 VPATH 使用

嵌套的 Makefile

每个文件都有自己的 Makefile，Makefile 互相调用子 Makefile。

案例：

我们看到有许多目录和外部 makefile，在每个目录下有 .c 程序和子 makefile：

在第一个目录 f1 中的子 Makefile 会把 f1.c 生成为 f1.o，放到 OBJS_DIR 的 obj 中：

• 我们注意到有一句 @echo $(SUBDIRS)
• @(RM) 并不是我们自己定义的变量，那它是从哪里来的呢？就是 make -f
• make -C $@
• export CC OBJS BIN OBJS_DIR BIN_DIR：是让子 Makefile 也可以调用这些变量。