一、前言

上篇博客，我们学习了 gcc 编译器。学会了如何在 Linux 上编译 C语言 代码。

对于我们平常练习是没问题的，但是如果有上百个源文件，该怎么办？难道还是一个个都用 gcc 编译为 .o 文件，最后将它们一起链接起来？

这肯定是不实际的，这使得编译成为了一个很麻烦的事情。

之前我们在 vs 中写代码时，使用快捷键就可以很快地进行程序的编译，或者直接执行程序，那么在 Linux 下能否也能实现这个功能？

能否减少编译代码时的风险，使编译更加快捷，一定程度实现自动化编译？

当然有，这就是我们 今天的目标之一：使用 make/makefile 构建一个简单的自动化工具。

另外 a n d u i n anduin anduin 还会讲解 make/makefile 的概念、原理和规则，从多层面理解透彻它们。

二、概念

makefile ：

   makefile 是一个文件。它是一个工程文件的编译规则，描述了整个工程的编译链接等规则。

   好的 makefile 文件可以使用一行命令来完成 “自动化编译” ，一旦写好 makefile ，就只要使用在 shell 提示符下输入 make 命令，从而完成对工程的编译，极大提高效率。

make ：

   make 是一个命令工具，用来一个解释 makefile 中文件中的指令。

   当已经编写好 makefile 文件后，只需要使用 make ，就可以执行 makefile 中的内容。

会不会写makefile，也从侧面说明了一个程序员是否具备完成大型工程的能力。

一个工程中的源文件不计数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作。所以使用好 make/makefile ，可以使得开发更加得心应手。

一句话总结：make 是一条命令，makefile 是一个文件，两个搭配使用，完成项目自动化构建。

三、demo 实现

在讲解 make/makefile 之前，我们先写一个小 demo ，以这个 demo 为基准，对其进行讲解。

makefile 文件需要创建在当前工程的目录下，makefile 文件的名称可以为 makefile 或 Makefile 。

假设当前工程下已经有了一个 test.c ，我们直接开始 demo 的编写：

这样 makefile 就编写好了，就两句话，这时编写的 makefile 可以完成对程序的编译。

我们返回终端，使用 make 就可以对 test.c 进行编译：

使用 make 指令后，makefile 的第二行内容被打印在终端，并且生成了可执行程序 test ，test 程序也是可以执行的。

四、原理与规则

上面写了一个小 demo ，那么这个 demo 实现的原理我们还不清楚，所以接下来 a n d u i n anduin anduin 来讲一下这中间的原理和规则。

1、依赖关系和依赖方法

在 myfile 文件中，有这样一句话：

test:test.c

刚刚测试过我们知道 test 是目标文件，而 test.c 则是原始文件。

而 test.c 经过 gcc test.c -o test 生成 test 文件。

它们之间的关系 ：

   test 依赖 test.c 生成，所以 test.c 是 test 的依赖文件 。它们之间的关系被称为 依赖关系 。

   test.c 生成 test 需要通过 gcc test.c -o test 指令，这条指令就是 依赖方法 。

① 感性理解

那么 依赖关系 和 依赖方法 如何理解呢？我来举个例子来帮助大家 感性理解 ：

例子1：

假设你在上大学，到月底了，你的生活费没了。那么这时你就打电话给你的老爹，来一个亲切的问候(要生活费)。

当你拨通电话，你说：“爸，我是你儿子！” 然后把电话挂掉。

这种情况能要到生活费吗？肯定不行，因为你只是向你的老爹 表明了你是谁(依赖关系) ，但是并没有告诉他 你要干什么(依赖方法) ，所以你的老爹一般是不会想着给你打钱，而是担心你的安全。

   所以，只有依赖关系没用，还需要有依赖方法，依赖关系和依赖方法需要同时具备。

例子2 ：

如果你在上大学，马上要考试了。你决定又给你的老爹打电话，说：“爸，我是你儿子！能不能帮我期中考？” 听完这句话，你的老爹思考了很久。于是决定连夜赶到你的学校，并请你体验了一顿 “七匹狼” 。

综上我们可以发现，你有依赖关系(表明了身份) ，你也有依赖方法(叫你老爹考试)，但是 依赖方法错误 ，也没有达到目的，反而造成错误结果。

这就是典型的有正确的依赖关系但是依赖方法错误。

   所以，正确的依赖关系必须具有正确的依赖方法。

例子3 ：

如果你有一天，又到了月底？你随意拨通了一串号码，和陌生人说："爸，我是你儿子！我没生活费了，给我打钱。"再以迅雷不及掩耳之势挂掉了电话。电话那头的人很懵。于是，当天晚上，你的梦里一直出现"功德-1，功德-1 … " 。

这个例子说明，你有了 正确的依赖方法(要生活费) ，但是你 没有正确的依赖关系(陌生人) ，这也办不成事。

   所以，正确的依赖方法也需要正确的依赖关系。

通过以上三个例子，我们得出结论，依赖关系和依赖方法必须同时具备并正确，缺一不可 。

② 深层理解

我们基于上层的感性理解，再通过一个 makefile 深层理解一下：

(实际上我们编译代码并不需要进行，这里只是为了理解 … ，平常就写成 demo 那样就可以)

在 makefile 文件中，共有四组依赖关系和依赖方法 ，当使用 make 调用 makefile 文件中内容时，便开始执行 makefile 中的内容：

   test 依赖于 test.o ，但是 test.o 并不存在，跳转到下一组依赖关系

   test.o 依赖于 test.s ，但是 test.s 并不存在，跳转到下一组依赖关系

   test.s 依赖于 test.i ，但是 test.i 不存在，跳转到下一组依赖关系

   test.i 依赖于 test.c ，test.c 存在，这时开始执行依赖方法

   由此开始，逐渐执行上面的依赖方法，一层层回退，逐渐生成 test.i 、test.s 、test.o ，最后生成可执行程序，make 执行完毕

我们发现，这一过程就像 数据结构的栈 。

当目标文件所依赖的文件不存在时，就会将依赖方法入栈，知道依赖关系匹配了，再执行相应的依赖方法，在按照栈的规则，逐渐将栈中的元素出栈，规则满足后进先出。

为了验证这些步骤是否都被执行，我们 make 一下看看：

依赖方法对应的文件都产生了，这也说明我们讲解的步骤是正确无误的。

2、清理

平时写代码时，经常需要反复编译，执行代码。

而在下一次重新编译之前，需要清理一下上次生成的可执行程序。但是清理的时候可能清理错误，不小心把源文件删了，这时又造成了问题。

而上面的步骤，我们也生成了很多附加文件(如 test.i 等)。

所以我们基于 demo 增加一个清理功能：

使用 make 测试一下：

文件也都删除了。

这是为什么，新增语句是什么意思？继续讲解原理。

① .PHONY 伪目标

.PHONY 修饰的对象是伪目标，伪目标的特性是：总是被执行的。

.PHONY 修饰的一定能被反复执行，但是能被反复执行的不一定被 .PHONY 修饰。

多次执行 make 和 make clean 试试：

(注：makefile 默认从上到下扫描只会执行第一组的依赖关系和依赖方法，所以默认执行第一组，这时使用 make 就可以；而 clean 为第二组，所以需要 make clean ，加上对应的关系。同理，对于第一组，使用 make test 也能执行。)

发现，第一组关系没有被 .PHONY 修饰，而不能重复执行。但是第二组 clean 可以重复执行 。

但是怎么证明 .PHONY 修饰对象之后，对象能被反复执行？口说无凭，所以，我们再验证一下：

给 test 加上修饰：

加上 .PHONY 修饰后，make 可以执行多次了，证明了 .PHONY 的作用。

但是能被反复执行的不一定被 .PHONY 修饰，就比如 clean ：

当 clean 去掉修饰之后，依然能被反复执行。

② .PHONY 的取舍

一般对于编译来说，是不加 .PHONY 修饰的。

因为编译是十分耗时间，特别是当工程量很大的时候，编译一两小时都不为过。所以防止对未修改的程序反复编译 ，一般编译时不加修饰。

但是 清理clean 是可以多次执行的，因为删除不太浪费时间，且可以反复清理，确认是否清理完毕。并且为了肯定清理可以被多次执行，所以通常用 .PHONY 修饰。

3、make 确定是否编译的方法

上面我们测试 make 时，发现当编译过一次后，继续使用 make 就无法继续编译了。但是 clean 是可以不加修饰反复执行的。原因我们也探讨过，但是 make 是如何确定是否要编译？

是这样的，对于程序来说，时间有两条线。第一条是源代码时间的一条线，第二条是形成的可执行程序的时间的一条线 。

而对于它们之间的次序，是先有源代码，再有可执行程序。

所以只要可执行程序的最近修改时间比源文件的修改时间晚，就认为当前可执行程序是最新的，为了减少时间和其他开销，于是不执行编译；否则执行编译 。

我们再重新生成可执行程序，并重复 make ，观察它们的时间：

观察时间，这里就要用到 stat 指令，它的 modify 就是最近修改时间 ，如果对 stat 指令不了解的小伙伴可以看这一篇：基本指令(一) （在 ls 指令部分）。

可执行程序 test 的时间明显比 源代码 test.c 晚，所以 make 并不能起作用。

那么基于对这个概念的理解，我们能否钻空子来 欺骗一下 make ？

补充：

   touch 指令为创建一个文件。若文件不存在则会创建一个文件；若文件存在则会把文件时间更新到最新。

使用 touch 更新一下 test.c 的时间，用 stat 观察时间，并反复 make 试试：

由此，我们发现可以使用 touch 来 “欺骗” make 来反复编译。这也侧面证明了： make 对于是否编译的决策是基于修改时间，而并不是基于文件内容是否修改 。

4、完整代码

test:test.c
  gcc test.c -o test  
.PHONY:clean                                                      
clean:
  rm -f test.i test.s test.o test

5、规则总结

对于依赖关系而言，: 左边为目标文件，: 右边为依赖文件

依赖方法前需要有一个 tab ，为固定格式

: 右边可以有多个依赖文件 ，: 右边通常被称为依赖文件列表

对于 : 右边，目标文件对应的依赖文件列表可以为空 (例如 clean)

makefile 默认执行第一组的依赖关系和依赖方法，对于第一组可以直接使用 make 执行，后面则需要 make + 目标文件

.PHONY 修饰的 伪目标可反复执行 ，但反复执行的不一定是伪目标

五、结语

到这里本篇博客就到此结束了。

实际开发中，好的 make/makefile 可以让项目开发事半功倍。所以构建自动化工具还是蛮重要的，可以大大提高开发的效率。

但是博主能力有限，对于博主当前，构建这么一个简单的工具就足够了。我们今天的重点是放在 make/makefile 的规则上。

感兴趣的小伙伴也可以往 makefile 中添砖加瓦，构建出自己开发的利器。

如果觉得 a n d u i n anduin anduin 写的不错的话，可以 点赞 + 收藏 + 评论 支持一下哦！我们下期见~