（8）Linux Makefile | 依赖关系，依赖方法

前言：

本篇文章会着重讲解Linux中的自动化构建代码工具: make/makefile的介绍与使用。

在Linux下编译代码时,每次都会输入

gcc code.c -o code.exe

 在删除可执行程序时,每次都会输入

rm -rf code.exe

这样非常的不方便,很麻烦,于是乎学习自动化构建代码是很重要的,它可以提高我们之后在Linux下编程的效率!

初识 Makefile 

首先,make是一条指令,而makefile是一个文件，makefile是需要自己创建的一个文件，并且makefile是一个具有特定格式的文本文件。

 在当前目录创建Makefile文件

现在有了 makefile 文件，下一步就是编写这个文件！

即在这个文件中添加对应的 "依赖关系" 和 "依赖方法"。

依赖关系与依赖方法

makefile：是在当前路径下的一个普通文件，它会包含两个东西

• 依赖关系（Dependency Relationship）
• 依赖方法（Dependent Method）

我们首先弄清楚一个概念，依赖是什么意思？什么是依赖？

假如你是个在校大学生，快要到月底了，这时候你可能就要打电话给你爸要生活费了。你打电话给你爸爸，说 "爸，我是你儿子。"，这就是表明依赖关系。你打电话告诉你爸你是他儿子的时候，实际上你的潜台词就是 "我要依赖你"。你给你爸打电话说："爸我是你儿子"，说完就把电话一挂，对于你爸来说会一脸懵逼 —— "这孩子今天怎么了，这是被绑架了？"，你爸就不太清楚了。也就是说，你在打电话时只是表明了依赖关系，但你并没有达到你想要做的目的（要下个月的生活费），所以正确的方法应该是："爸，我是你儿子，我要下个月的生活费。"，你表达了你是谁，并且要求给你打钱。

我是你儿子 —— 表明了 "依赖关系"，因为依赖关系的存在，所以才能给你打钱。

打钱 —— 就是 "依赖方法"，当你把依赖关系和依赖方法表明时，你就能达到要钱的目的。

依赖关系不对，依赖方法再对也没有用，比如你的舍友给你爸打电话，说："我是你儿子的舍友，给我打钱！"，你爸绝对不会打钱的。

依赖方法表明了，依赖方法不正确同样没有用，比如你打电话给你爸：说："我是你儿子，给我打钱我要充游戏！"，你爸也不会给你打钱的！

通过上面的比喻，相信你已经知道什么是依赖关系和依赖方法了，他们必须都为真。

依赖关系和依赖方法都要为真，才能达成要钱的目的！

makefile 里面表明的就是依赖关系和依赖方法。

写一个最简单的 Makefile

演示：写一个最基本的 Makefile

第一行的意思是mytest依赖于test.c。依赖关系写好后要写依赖方法（必须以Tab键开头）

gcc编译test.c形成一个mytest的可执行程序

mytest:test.c
    gcc test.c -o mytest

至此，我们就把一个最基本的 Makefile 写完了。

我们来 cat 看一下我们写的 Makefile，第一行是依赖关系，紧接着第二行是依赖方法。

注意：依赖关系后面紧跟依赖方法时前面要空一个 ，再写依赖方法。

此时我们就有了一个最基本的 Makefile 了，我们编译 mytest.c 文件就可以不用再敲 gcc 命令了！

直接在命令行中输入：

$ make

 

 输入 make，这里就自动形成了可执行程序，会帮我们从 Makefile 去找依赖关系和依赖方

我们看看发生了什么：

"这不还是要输 gcc 命令吗？这和我在命令行有什么区别？" 

当前让你产生这种感觉，主要是因为：

① 上面我们写的 makefile 是最简单的 makefile 了，自然和命令行没什么差别。

② 我们目前的项目结构简单，如果后面遇到大的项目结构你就知道 Makefile 有多香了。

最最最重要的是 ——

以后我们在 Linux 下编译代码就不需要敲 gcc 命令了，直接 make 就可以了。

它会给我们带来很多便捷，如果是第一次接触，现在可能还体会不到，后面慢慢就能体会到了。

 项目的清理

刚才我们说的 make 就相当于 VS 下的 "生成解决方案" ：

但是 VS 下好像还有 "清理解决方案" 这样的功能，那我在 Linux 下也想拥有，怎么办？

举个例子： 

我们现在不想要这个可执行程序了，放在之前我们会直接 rm 掉这个文件。

但是假设有这样的一个场景：一个程序生产了大量的临时文件，你岂不是要疯狂的 rm？

无脑删又很容易把源代码删掉，这个时候我们就可以在 Makefile 里实现 "清理解决方案" 的功能！

.PHONY:clean
clean:

我们再次打开：vim Makefile

 clean  没有依赖文件，也是存在依赖关系的，只不过这个  clean  没有依赖列表。

它后面的相当于是个孤儿，而  clean  被 ​.PHONY

 修饰成伪目标（这个我们下面会说）。

后面的  rm -f mytest  为依赖方法，我们现在来用一下看看效果如何！

刚才我们编译用的是 make，清理我们用 make clean：

输入效果如下：

 

可执行程序没了-----清理成功

注意事项：再次强调，依赖方法前面必以 tab 键开头

 多文件的 makefile

我们来演示一下多文件的 makefile。

我们先创建 3 个文件，分别是 main.c，test.c 和 test.h ：

vim 分别打开这三个文件，我们写一点东西进去：

 此时如果我们 gcc，我们可以：

gcc -o hello main.c test.c

我们把 test.c 跟在 main.c 后面，这里不放 test.h 的原因是因为头文件在预处理阶段就已经展开到源文件中了。

现在我们开始写 makefile：

我们想生成的 hello 文件需要依赖于 main.o 和 test.o

但我们没有 .o，所以我们还需要进一步解释一下 main.o 和 test.o 是依赖谁的。

值得一提的是，下面两种写法都是可以的：

# 写全是这样的
gcc -c main.c -o main.o   
# 实际上，如果你不写后面的，makefile也会自动给你形成同名.o
gcc -c main.c   

制作好 makefile 之后，我们 make 一下看看效果如何：

效果很好，我们再把清理功能写一下：

 

这里我们需要删除  文件，星号代表的是通配符，意思为 "  " 左边所有的内容我不关心，

只要它以  结尾的，就删掉。此外， 和  之间没有空格！

看看效果如何：

make 就相当于 VS 中的构建项目，而 make clean 就相当于是清理项目。

除此之外,在makefile中还可以定义变量

这样写你还认识之前的代码吗?在要替换的内容前加上$和()即可，像C语言定义变量一样编辑代码

依然正常：

对比一下：

并且,可以用$^代表依赖关系的左边，可以用$@代表依赖关系的右边

这里的$^就代表test.c

如果你不想一条指令被打印在显示器
可以在指令前加上@符号

PHONY 伪目标

PHONY 定义伪目标 

.PHONY是将clean指令修饰成了伪目标

不知道你有没有观察到，我们的 makefile 有两个目标文件：

我们在 make 的时候，默认只帮我们生成 makefile 中的 test.c 目标文件。

而 make clean 是制作指定名称的目标文件，做清理的工作，我们首先来思考一个问题：

❓ 思考：为什么 make 的时候它总是执行第一个呢？

makefile 在自顶而下进行形成目标文件时，它可以根据你的需求形成多个目标文件。

我们这里有两个目标文件，一个是 test 一个是 clean，凭什么我 make 执行的是 test 而不是 clean？答案很简单，就凭我 test 是在前面写的！

 如果我们把它们两的顺序换一下：

然后我们再来进行 make 看看：

此时make就是clean的操作了,如果要生成test.c，自然要make test了，和钢材的make clean一样

所以 makefile 在形成文件时会自顶而下扫描，默认只会形式第一个目标文件，执行该依赖关系的依赖方法。 

但是我们一般还是喜欢把形成可执行程序放在前面，也就是让 makefile 默认去形成

那这个  .PHONY到底是干什么的呢？现在我们正式介绍一下这个东西。

​.PHONY 是 makefile 语法格式的一个关键字，表明 "总是被执行的" 。

• 比如 clean 被 .PHONY

•  修饰时，表明 clean 是总是被执行的。

这个 "总是被执行" 这句话真的非常的莫名其妙，我们先通过代码来看看什么是 "总是被执行" ！

总是不被执行 

现象演示：总是不被执行

我们多次 make 之后它仍然是会提示 “make: `mytest` is up to date.”  这段话。

貌似只有第一次 make 的时候才会才会帮我们形成一个全新的 mytest ，再之后多次进行 make，

就会告知你 mytest 已经是一个可执行程序了，不能再生成了。
这种现象就叫做 "总是不被执行的" ，你已经是最新的可执行程序了，干嘛要再去形成呢。

总是被执行 

我们用.PHONY修饰test.c，现在test也变成了总是被执行了，

现象演示：总是被执行

被 ​ .PHONY 标记后，我们每次 make 都会执行 gcc mytest.c -o mytest

总是被执行：无论目标时间是否新旧，照样执行依赖关系。

而我们一般不太建议、喜欢把我们形成的目标文件定义成伪目标，而是喜欢把清理定义成伪目标。

这也正是为什么我们每次 make clean 都能帮我们执行清理的根本原因。

思考：那 makefile 是如何识别我的 exe/bin 文件是新的还是旧的呢？

ACM 时间包含 Access 时间、Modify 时间 与 Change 时间。

这个 Modify 和 Change 有什么区别呢？

我们知道，"文件 = 内容 + 属性"

如果是内容发生改变，就是 Modify；如果是属性发生改变，就是 Change。

修改内容也有可能引发 Change 的改变，因为修改内容可能会引起 change time 的变化

我们打开文件修改，Access 应不应该改变呢？我们读取 Access 变不变？

要变的！但是现在不会变！因为访问文件的频率是最高的，Modify 和 Change 是不得不变的，不变的化文件就不对了。但是我们大多数情况修改文件属性和修改文件内容是很低频的事情，但打开文件是非常高平的事情，Linux 后期内核对 Access 进行了优化，将文件打开访问，打开时间不会变化，累计一段时间后他才会变化。如果不这样，打开文件这种高频率的事情，一旦更新 Access 时间，就要将数据刷新到磁盘上，这实际上一个很没效率的事情。

具体 Access 的调整策略取决于 Linux 的版本。

答案：通过对比你的源文件和可执行程序的更改时间 (modify time) 识别的新旧。 根据原文件和可执行程序的最近修改时间，评估要不要重新生成。

现在我们再回头看刚才的问题：什么是 "总是被执行呢" ？

"总是被执行" 就是 忽略对比时间 (modify time)，不看新旧，我让你执行你就给我执行。

谢谢~~