Linus - make命令和 makefile

make命令和 makefile

如果之前用过 vim 的话，应该会对 vim 又爱又恨吧，刚开始使用感觉非常的别扭，因为这种编写代码的方式，和在 windows 当中用图形化界面的方式编写代码的方式差别是不是很大。当你把vim 用熟悉的之后，虽然没有刚开始那么别扭了，但是当你在编写一些大型项目的时候，vim 怎么用都不习惯。

而 makefile，就是一个可以定义一系列规则，来指定那个文件先编译，那个文件后编译，哪些文件需要重新编译，甚至进行更复杂的操作。

makefile 相对与 vim来说，他可以实现--"自动化编译 "，一旦把 makefile 当中的各个文件的执行过程写好只好，只需要一个 make 命令，就可以让由makefile 实现的各个文件的编译顺序的整个工程进行 完全自动的编译 ，这极大的提高了软件开发的效率。

makefile 编写链接关系和链接方法

首先要明确的是， make 是一个命名，它会默认在本目录下寻找名字叫做 "makefile" 或者 "Makefile" 也就是说，首字母大不大写其实是无所谓的。

一般情况下，makefile是创建在 源文件的同级目录（当前目录）下创建的，我们用一个小例子来看 makefile和 make 的使用过程：

我们新建立一个文件夹（mk），在这个文件夹当中进行操作：

此时这个文件夹当中什么都没有，是空的，我们创建一个 text.c 文件：

然后在其中简单些一些代码：

此时，就有了源代码文件，然后，我们建立的 makefile 文件要和这个源代码文件（text.c）文件在同级目录下：

然后我们使用vim 打开编译 makefile 文件，在 makefile 文件当中进行以下书写：

在 " : " 的右边是与 makefile同级目录之下的某一个源代码文件；而在 " : " 的左边是由右边的源代码文件即将生成的可执行文件（这个在外部使用make 名字之后才会生成）。

由上述过程，我们就编译好了， text.c 这个源代码文件由 makefile 生成可执行文件的过程。

此时我们只需要在 makefile 的同级目录 下，使用 make 命令 就可以在 同级目录之下 生成一个 text 的可执行文件：

由上述结果可知，使用 make 之后，还会再屏幕上打印编译过程。

我们把上述的用 " : " 把源文件和对应可执行文件连接在一起的关系，叫做链接关系。关于链接关系我们下述在具体说明。

但是，上述我们只是写了一个链接关系，并没有指定这个源代码要使用什么样的编译方式，我们可以在 " : " 说明之后，在下面把编译规则写上：

向上述就表示买吧 text.c 源代码文件以 gcc 的方式编译成 text 可执行文件。我们把这个中方式叫做依赖方法。

注意：此处的依赖方法我们可以看到前面是空格开头的，这里不能是空格分割，必须使用 tab 键进行分割：

往后，我们先要编译 text.c 这个源代码文件的时候，就可以不用再使用 gcc 命令来编译这个文件了，直接在上述同级目录之下，使用 make 命令就可以直接生成 text 可执行文件。（具体方式和上述演示是一样的，这里就不演示了）

makefile 编写删除源文件规则

当我们不想使用上述的 text 这个可执行文件时，我们当然可以用 rm 删掉这个 text 可执行文件，但是，用 rm 删除文件的风险太大，很容易写错文件名，而导致删错文件，要知道，在 linux 当中可是没有像 windows 当中的回收站一样的东西，在linux 当中删除某一个文件就是真的删除掉了。

所以，在 makefile 当中不能只提供编写源代码文件链接关系和链接方法，还应该提供删除的方式：

我们可以在其中写一个类型 make 的命名，向上述我就写了一个 make clean 的命令（这个命令的名字是自定义的），然后在后边写上删除 text 这个可执行文件：

在使用 make clean 这个命令之后，在目录当中就没有 text 可执行文件了。

依赖关系和依赖方法

如上所示：text:text.c 是一个依赖关系， gcc -o text text.c 是一个依赖方法，那么这里的依赖关系和依赖方法是什么呢？

我们举一个例子：小明和他的爸爸，是一种依赖关系，当小明向他的爸爸要零花钱的时候，小明说："爸，给我打100 块钱"，类似的话语，那么小明只有管他的爸爸叫爸，这是一种依赖关系，如果他问他的室友的爸爸，给他打钱，小明和他室友的爸爸没有依赖关系，那么室友的爸爸为什么要给小明打钱呢？

只有小明和他父亲，是一种依赖关系，所以，小明的爸爸才会给他打钱；

但是，确定依赖关系之后，已经确定是要打钱的了，但是，如何打钱，微信还是支付宝，还是打银行卡，就要有人去确定，所以这时候就有了打钱的方法，也就是依赖方法。

那么，换到 makefile 当中也是一样的，text 和 text.c 是一种依赖关系，只有通过 text.c 才能生成 text 可执行文件，对于如何生成可执行文件，如上述：使用 gcc -o 的方式生成可执行文件。

当前的 text 依赖的是 text.c 这个一个源文件来生成的，如果有两个，那么后面就跟两个，三个就跟三个，是依靠这 text.c 一个源文件生成的 text 可执行文件（目标文件）。所以，就告诉 makefile，目标文件是 text，这个text 依赖的文件是 text.c。但是光有依赖关系是不够的，makefile还需要知道如何根据 text.c 文件生成 text 目标文件，他也是需要知道的，所以，才有了 依赖方法。

关于make 指令

上述是有 text.c 文件一步到位生成的 text 可执行文件，我们还可以写得更复杂一点，把 c 源代码文件生成可执行文件的整个过程都是意义列举出来：

此时 make 命令打印：

而且，发现，此时在文件夹当中不止有 text 可执行文件了，还有上述生成的所有的中间文件：

其实是因为，在上述当中，我们要想从 text.o 文件生成 text 可执行文件，makefile 就要从当前目录之下来寻找 text.o 文件，但是此时目录当中是没有 text.o 文件的，所以他就会接着走链接关系，发现 text.o 是由 text.s 生成的，但是此时目录当中还是有 text.s，他又会继续寻找链接关系，发现是 text.i 生成的 text.s········一次类推。

最后找到 text.c ，生成了text.i ，然后逆向的一直生成到最终的目标文件 text 可执行文件。

也就是说，makefile 的最终目的是要生成目标文件，而目标文件的依赖关系的源文件，他会先去看目录当中有没有，有就直接生成，没有的话，就会去寻找这个号源文件的依赖关系，然后递归式的去生成目标文件的依赖文件。

这个特征（过程），就特别像一个函数递归的过程。而上述的目标文件就是这个递归的出口（结束条件），整个的结构，在保存这些依赖关系的时候，是一种栈式的结构。

而且，上述过程，不是需要按照顺序来书写链接关系的，就算是乱序，都是可以编译出来的：

make 指令：

当然，虽然能打乱顺序，但是不能缺胳膊少腿，一个工程当中的文件编译顺序，缺一个他肯定是不能自动推导的 ：

输出：

总结：make 命令可以自动推导 makefile 的链接关系，就算其中的顺序是打乱的，只要存在，就会自动推导。其中的依赖关系是利用栈式的结构进行存储的。

在上述你也发现了，我们的 clean 指令，写的是删除了4 个文件，当我们在外部输入 make clean 的时候，这个 4 个文件就都会删除，非常的方便：

注意：make 的默认动作是，把 makefile 当中的第一个目标文件作为 make 的默认动作；

比如上述，把 clean 放到 text 目标文件的第一行的话，那么我们使用 make 指令是不会执行 text 的，而是执行 clean：

使用 make 指令：

如上述所示，我们直接使用 make 指令，直接执行的是 clean 指令，而不是生成 text 可执行文件。

而 make + 目标文件名（如上述的 make clean），就是执行在makefile当中的目标文件。

在本目录下有 make + 目标文件的目标文件时，就不能再次 make 了：

发现，当目录当中没有目标文件的时候，可以用 make 编译，但是当有目标文件的时候，就不能再次编译了，但是，当上述情况发生之后，我们又去修改了 text.c 的代码，发现make 有可以进行编译了：

因为，如果在第一次编译之后，源代码没有进行修改，那么是没有必要进行再次编译的（提升效率）。

我们在，windows 当中编写代码的时候，有时候报错了，但是我们已经进行修改了，但是修改之后还是报错，当我们重新生成解决方案之后，程序又好了，在期间我们没有修改过代码。其实原因就和上述是一样的，有些编译器会帮我们去辨别当前代码有没有被修改过，如果没有，那么也就没有再次编译的必要了，但是有的时候，可能编译器判断不是很灵敏，需要我们手动编译一下。

那，上述的不给继续编译，和判断源代码文件是否进行修改是如何做到呢？

我们都知道，可执行文件是在源文件的基础之上生成的，先有源文件，才有可执行文件，所以，一般而言，源文件的最近一次修改时间 是要比 可执行文件要早的。

如果，我们修改了源文件，此时在目录当中还是有可执行文件的，那么源文件的实现一定要比可执行文件的晚。

所以，只需要比较可执行文件的最近修改时间和源文件的最近修改时间：

如果.exe 新于 .c 说明源文件是老的，不需要重新编译。
如果.exe 于旧 .c 说明源文件是新的，需要重新编译。

对于 可执行文件和源文件的修改时间，一般是不会一样的，除非是用一些修改文件时间的命令。

stat命令（验证make 利用文件时间差异实现新老文件判断）（文件的三个时间）

stat命令用于访问某一个文件的时间问题，那么，可以使用 stat命令来查看源文件和可执行文件的一些时间：

最近访问时间就是访问了这个文件的最近一次时间，比如 cat ，vim 都算是访问了这个文件。不管是你要查看还是修改这个文件当中的内容，都是要访问这个文件的，所以最近访问时间，几乎是你对这个文件任何操作的最近时间。这个时间更改的频率是非常高的。
文件内容修改时间，就是文件当中存储的内容，最近一次的修改时间。
文件属性改变时间，就是文件当中存储的文件的属性，最近一次的修改时间。

上述的三个时间可能不是割裂的，比如修改了文件内容，不仅是 Modify 会改变，可能 Access 也会改变，系统可能判定为当前一次操作就是一个文件的访问操作，而且修改文件的内容可能会修改到文件属性，所以，都不是割裂的。

现在，我们修改一下文件的属性：

发现文件的 Change 时间已经被修改了。

此时 Modif 和 Access 都没有被修改，说明在当前系统下，认为 chmod 命令不算做是一次文件的访问。

其实在早期的linux 当中 access 在上述情况是要被修改的，但是也正是 Access 被修改的频率太高了，所以，如果有多个用户在修改访问这个文件，那么 Access 都要被修改，而 Access 被修改是要写进日志的，文件还是在磁盘上保存的，要修改磁盘当中 Access 被修改的日志的话，就是要频繁的修改磁盘当中的内容，这效率就太低了。

所以，现在就减少了Access 修改的次数，来变相修改操作系统的效率。

如果实在想要修改这个文件的当中的所有的时间，可以使用 touch （要修改的文件）文件名来实现 。touch + 目录当中不存在的文件名，就是创建一个文件，如果 touch + 目录当中已经有的文件，就是更新这个文件的所以时间。

make 命令就是把两个文件各种各样的时间，转化成时间戳，然后按照时间戳的大小，来比较谁新谁旧。

验证：

首先我们先用 make 编译一次，打印出源文件时间和可执行文件的文件内容时间：