(8)Linux Makefile | 依赖关系,依赖方法

前言:

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

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

gcc code.c -o code.exe

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

rm -rf code.exe

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

初识 Makefile 

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

(8)Linux Makefile | 依赖关系,依赖方法_第1张图片

 在当前目录创建Makefile文件

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

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

依赖关系与依赖方法

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

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

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

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

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

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

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

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

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

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

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

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

写一个最简单的 Makefile

演示:写一个最基本的 Makefile

(8)Linux Makefile | 依赖关系,依赖方法_第2张图片

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

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

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

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

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

(8)Linux Makefile | 依赖关系,依赖方法_第3张图片

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

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

直接在命令行中输入:

$ make

 (8)Linux Makefile | 依赖关系,依赖方法_第4张图片

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

我们看看发生了什么:

(8)Linux Makefile | 依赖关系,依赖方法_第5张图片

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

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

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

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

最最最重要的是 ——

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

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

 项目的清理

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

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

举个例子: 

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

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

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

.PHONY:clean
clean:

我们再次打开:vim Makefile

(8)Linux Makefile | 依赖关系,依赖方法_第6张图片

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

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

 修饰成伪目标(这个我们下面会说)。

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

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

输入效果如下:

 (8)Linux Makefile | 依赖关系,依赖方法_第7张图片

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

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

 多文件的 makefile

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

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

(8)Linux Makefile | 依赖关系,依赖方法_第8张图片

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

(8)Linux Makefile | 依赖关系,依赖方法_第9张图片 此时如果我们 gcc,我们可以:

gcc -o hello main.c test.c

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

现在我们开始写 makefile:

(8)Linux Makefile | 依赖关系,依赖方法_第10张图片

我们想生成的 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 一下看看效果如何:

(8)Linux Makefile | 依赖关系,依赖方法_第11张图片

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

 (8)Linux Makefile | 依赖关系,依赖方法_第12张图片

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

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

看看效果如何:

(8)Linux Makefile | 依赖关系,依赖方法_第13张图片

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

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

(8)Linux Makefile | 依赖关系,依赖方法_第14张图片

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

依然正常:

对比一下:

(8)Linux Makefile | 依赖关系,依赖方法_第15张图片

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

(8)Linux Makefile | 依赖关系,依赖方法_第16张图片

这里的$^就代表test.c

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

PHONY 伪目标

PHONY 定义伪目标 

(8)Linux Makefile | 依赖关系,依赖方法_第17张图片

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

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

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

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

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

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

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

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

(8)Linux Makefile | 依赖关系,依赖方法_第18张图片

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

(8)Linux Makefile | 依赖关系,依赖方法_第19张图片

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

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

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

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

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

  • 比如 clean 被 .PHONY
  •  修饰时,表明 clean 是总是被执行的。

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

总是不被执行 

现象演示:总是不被执行

(8)Linux Makefile | 依赖关系,依赖方法_第20张图片

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

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

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

总是被执行 

(8)Linux Makefile | 依赖关系,依赖方法_第21张图片

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

现象演示:总是被执行

(8)Linux Makefile | 依赖关系,依赖方法_第22张图片

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

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

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

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

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

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

(8)Linux Makefile | 依赖关系,依赖方法_第23张图片

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

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

如果是内容发生改变,就是 Modify;如果是属性发生改变,就是 Change。

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

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

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

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

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

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

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


谢谢~~

 

 

你可能感兴趣的:(Linux学习之路,linux,运维,服务器)