【看表情包学Linux】探讨项目构建问题 | Makefile | 依赖关系与依赖方法 | 伪目标 PHONY

阿里云国内75折 回扣 微信号:monov8
阿里云国际,腾讯云国际,低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号:monov8 飞机:@monov6

  🤣 爆笑教程 👉 《看表情包学Linux》👈 猛戳订阅  🔥

💭 写在前面本章我们要学习的是 makefile。会不会写 makefile从一个侧面说明一个人是否具备完成大型工程的能力。一个工程中的源文件不计其数按类型、功能、模块分别放在若干个目录中makefile 定义了一系列的规则来指定哪些文件需要先编译哪些文件需要后编译哪些文件需要重新编译 甚至于更复杂的功能操作。话不多说让我们开始吧

   本篇博客全站热榜排名16


Ⅰ.  初识 Makefile

0x00 引入聊一聊项目构建的话题

 项目构建这个话题说人话就是关于你的项目和编译的话题。

对于项目构建的话题一直用 VS 的同学可能会感叹道

" 诶……我就从来就没这样的困扰我在 VS 下创建多文件运行直接特喵的 Ctrl + F5 就完事了 "

确实编译时你需要按个键就能做到编译调试运行编译个项目真的轻轻松松。

 那是因为 VS 帮你自动维护了对应的项目结构

❓ 思考你可以试着思考一下下面的问题

  • 多文件 .c,\, .h,\, .cpp  我们先编译哪一个程序
  • 链接需要哪些库
  • 库和头文件等在哪里找
  • 整个项目结构该如何维护

上述问题你在 VS 下压根就没关心过因为 VS 下都帮我们屁股擦得干干净净 ~

你只需要在你的 VS 下需要.c 就创建 .c需要.h就创建 .h

需要包含头文件就 #include 头文件因为 VS 自动帮你维护了项目的结构

也不需要牵扯先编哪个后编哪个的话题但是在 Linux 下这些东西该如何去弄呢

💭 举个例子

没有请问你要先编哪个后编哪个呢最后怎么形成可执行程序呢

若尚未学习 makefile你怕不是会用 gcc 命令一个个去编编完之后还要把它们链接起来。

" 啊这这样成本也太高了太烦了吧……"

如果你项目中存在 100 个 .c 70 个 .h你在 VS 下编译直接运行就行各种调各种编都可以。

但是如果这是在 Linux 中有这么多的头文件和源文件你就得把这些源文件一个个变成 .o

然后再一个个把 .o 链接起来形成可执行头文件如果找不到的话还得自己去处理……

这些事在 Linux 中就需要我们去做了为了能让这样的工作更适合地球人于是就有了 makefile。

不是集成环境也没关系我们可以使用 Makefile 来统一解决这样的问题。

0x01 什么是 Makefile

什么是 Makefile

在我们 Linux 当中就是 make / makefilemake 是一个命令makefile 是一个文件。

为了不增加学习的成本前期我们只用一个头文件给大家演示并且会讲的浅一些

💭 演示如何使用 Makefile

如果放到之前我们如果想编代码会自己 gcc但实际上写 Makefile 也要 gcc

但 Makefile 能让你不在命令行中打 gcc 命令操作这能避免一些比较尴尬的情况。

比如下面这种 mytest.c mytest 的顺序写反了的情况

$ gcc mytest -o mytest.c

" 这……尬的我徒手抠出一个三室一厅 "

写选项时如果把生成可执行程序与源代码搞反了又恰巧存在一个可执行那源代码可能就寄了

目录下存在一个叫 mytest 的可执行此时如果不小心把选项写反后果就是源代码直接消失

$ gcc mytest -o mytest.c   ❌  写反了!

这种场景一不小心写反可执行程序就覆盖掉了原文件最后导致你的源代码都没了……

由此可见在命令行操作时如果出现误操作就会翻车。

" 毕竟人被杀就会死道理大家懂得都懂。"

正是因为这些悲剧的存在使得 Makefile 的光芒愈发温暖

" Makefile我滴神我好喜欢你为了你我要疯狂的写bug"  

 

0x02 依赖关系与依赖方法

下面我们来正式介绍一下 MakefileMakefile 需要两个东西我们先介绍第一个东西。

  • 需要在你当前路径或代码路径下创建一个 "Makefile" 或 "makefile" 文件首字母大小写均可

我们先做一些准备工作然后创建一个名为 makefile 的文件

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

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

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

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

 第一次看到这两个词的朋友可能会一脸懵逼

不如这样我来举一个生活当中的例子帮助大家去理解它们的意思

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

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

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

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

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

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

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

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

(\textrm{DR} \, \, \wedge \textrm{ DM}) \rightarrow \textrm{makefile}

makefile 里面表明的就是依赖关系和依赖方法按照现阶段的认识我们可以倒推一下

Ⅱ. 实现简单的 Makefile

0x00 写一个最简单的 Makefile

💭 演示写一个最基本的 Makefile

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

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

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

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

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

直接在命令行中输入

$ make

🚩 输入效果

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

我们来看看这小B窄汁都做了些什么 ——

 这个 3我就是故意写这么大的你就说你能把我怎么办吧

 看到这里有的人可能会觉得 —— 

"你这不是脱裤子放屁么这不还是要输 gcc 命令吗这和我在命令行有什么区别"

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

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

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

" 哈哈毕竟谁会想敲一百多行 gcc 呢……"

 最最最重要的是 ——

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

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

0x01 项目的清理

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

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

" 得不到就毁掉不我们得不到还可以去 Makefile 嘛"

💭 举个例子 

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

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

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

.PHONY:clean
clean:

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

它后面的相当于是个孤儿而  clean  被 \textrm{​{\color{Red} .PHONY}} 修饰成伪目标这个我们下面会说

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

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

🚩 输入效果如下

此时如果想清理代码在命令行直接输入 $make clean 即可。

📌 注意事项再次强调依赖方法前面必以 tab 键开头红色框标记处

0x02 多文件的 makefile

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

我们先创建 3 个文件分别是 main.ctest.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 一下看看效果如何

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

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

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

看看效果如何

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

Ⅲ. PHONY 伪目标

0x00 .PHONY 定义伪目标

目标文件和伪目标给我的一种感觉就是好像都是目标文件啊这就像正规军和伪军都是军队。

不管是目标文件还是伪目标最终目的都是要根据自己的依赖关系执行依赖方法。

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

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

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

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

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

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

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

然后我们再来进行 make 看看

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

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

那这个 \textrm{​{\color{Red} .PHONY}} 到底是干什么的呢现在我们正式介绍一下这个东西。

\textrm{​{\color{Red} .PHONY}} 是 makefile 语法格式的一个关键字表明 "总是被执行的" 。

  • 比如 clean 被 \textrm{​{\color{Red} .PHONY}} 修饰时表明 clean 是总是被执行的。

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

0x01 总是不被执行

"总是被执行"  就意味着还有 "总是不被执行" 我们先来看看什么是 "总是不被执行"

💬 现象演示总是不被执行

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

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

就会告知你 mytest 已经是一个可执行程序了不能再生成了。

这种现象就叫做 "总是不被执行的" 你已经是最新的可执行程序了干嘛要再去形成呢。

如果自己的源代码已经用最新的源代码编译链接形成可执行文件了那么编译器就不会再帮我们再重新根据你的 makefile 再重新给你生成了。因为既然变都没变还给你生成那岂不是既浪费时间又浪费资源

现在你可以不用去想它是怎么做到的我们已经演示了 "总是不被执行" 的情况了。

0x02 总是被执行

我们刚才看了 "总是不被执行" 的现象我们试试给我们的 mytest 也用 \textrm{​{\color{Red} .PHONY}}让它从默认的 "总是不被执行" 变成 "总是被执行" 看看

现在 mytest 也变成了 "总是被执行" 了现在我们来看看 "总是被执行" 是个什么现象

💬 现象演示总是被执行

被 \textrm{​{\color{Red} .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)不看新旧我让你执行你就给我执行。

📌 [ 笔者 ]   王亦优
📃 [ 更新 ]   2023.1.3
❌ [ 勘误 ]   /* 暂无 */
📜 [ 声明 ]   由于作者水平有限本文有错误和不准确之处在所难免
              本人也很想知道这些错误恳望读者批评指正

📜 参考资料 

C++reference[EB/OL]. []. http://www.cplusplus.com/reference/.

Microsoft. MSDN(Microsoft Developer Network)[EB/OL]. []. .

百度百科[EB/OL]. []. https://baike.baidu.com/.

比特科技. Linux[EB/OL]. 2021[2021.8.31 xi

阿里云国内75折 回扣 微信号:monov8
阿里云国际,腾讯云国际,低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号:monov8 飞机:@monov6
标签: linux

“【看表情包学Linux】探讨项目构建问题 | Makefile | 依赖关系与依赖方法 | 伪目标 PHONY” 的相关文章