Make 一般是在 Unix 环境下使用的自动化编译工具。他本身不是编译器,而是将众多 C/C++源文件组织起来,确定其编译方式和编译顺序的工具。一旦我们写好的 Makefile 配置文件,那么无论多么复杂的工程我们都可以用一条 make 命令来解决。事实上,尽管通常和 C/C++搭配起来使用,make 也能应用到其他的编程语言之中。
在使用 make 过程中的第一个核心问题是处理文件依赖的问题。例如:
1 | foo.o : foo.c defs.h # foo模块 |
这里 foo.o
依赖于 foo.c
和 defs.h
。当后面两个文件发生变化时,make 会自动运行 cc -c -g foo.c
命令更新 foo.o
文件。但是,随着项目扩大。这种文件之间的依赖关系会变得非常复杂,一个小的改动可能会涉及到众多依赖关系的修改。因此有必要在项目的开始就引入自动构建依赖关系的工具链。
在跟我一起写 Makefile:书写规则这篇教程中,提到了编译器的一个特性:大多数的 C/C++编译器都支持一个 -M
的选项,即自动寻找源文件中包含的头文件,并生成一个依赖关系。例如如果我们执行
1 | cc -M main.c |
其输出是:
1 | main.o: main.c defs.h |
注意如果你用的是 GNU 的 C/C++编译器,你得用"-MM"参数,不然,"-M"参数会把一些标准库头文件也引入进来。
这篇教程里面详细阐述了如果在 Makefile 中使用这一特性的方法,综合而来就是:
1 | # 对于每个.c源文件,建立一个描述其依赖关系的.d依赖文件 |
上述命令中
sed
命令的作用是在依赖关系对中,在左侧加上.d 文件本身。即 将
1 main.o: main.c defs.h转换成
1 main.o main.d : main.c defs.h
然后将生成的依赖关系文件include
进来
1 | sources = foo.c bar.c |
在教程中还提到,这个 include
要放在默认目标之后,避免 include 载入的文件的目标替换了默认目标。
走完上面的流程,会得到一个类似的如下内容的文件:
1 | %.d: %.c |
不过按照这个Makefile
第一次执行的时候会产生一个问题:第一次执行时,.d 文件尚未生成,这里的include
导入的文件不存在,会产生如下的错误信息
1 | Makefile:8: main.d: No such file or director |
最后是通过面向 google 的 debug 找到了 Autodependencies with GNU make 这篇 2001 年的文章,细致地阐述了这个问题。解决的关键在于在 include 前面添加一个 dash(-),其作用是:如果 include 的对象不存在,make 继续执行,后续 make 会自动生成.d 文件,然后执行 include。这篇新的教程提供的完整 Makefile 示例如下(和前面的形式有不同,但是思路是一致的):
1 | OBJS := foo.o bar.o |