目录
5.2 文件的Access时间（访问文件时间）特殊的时间更新策略
5.3 关于可执行程序的文件时间和源文件的文件时间该对比哪个文件时间比较合适呢？
1.背景
会不会写makefile，从一个侧面说明了一个人是否具备完成大型工程的能力
一个工程中的源文件不计数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作
makefile带来的好处就是——“自动化编译”，一旦写好，只需要一个make命令，整个工程完全自动编译，极大的提高了软件开发的效率。
make是一个命令工具，是一个解释makefile中指令的命令工具，一般来说，大多数的IDE都有这个命令，比如：Delphi的make，Visual C++的nmake，Linux下GNU的make。可见，makefile都成为了一种在工程方面的编译方法。
make是一条命令，makefile是一个文件，两个搭配使用，完成项目自动化构建。
2.make和makefile的演示
3.依赖关系和依赖方法
依赖关系：我为什么要帮你。
依赖方法：我怎么帮你。
4. makefile的语法
1：
make和makefile的时候，形成目标文件的时候，默认是从上到下扫描makefile文件， 默认形成的是第一个目标文件文件。
2;
默认只形成一个目标文件。
我们发现无法对一个依赖文件文件没有修改的目标文件多次进行make。 即无法对新的可执行程序进行重新编译。
那么make和makefile是怎么知道可执行程序是比较新的呢？
这个是对比时间对比出来的，只要可执行程序的最近更改时间，比所有源文件的修改时间都要新，这样就说明他是最新的文件。
那么源文件的修改时间会不会和可执行程序的最近修改时间完全一致呢？
不可能的，程序编译和代码修改都需要时间，逻辑上他们两个的时间根本就不会是一样的。
当多个源文件编译形成可执行程序时，只对其中的一两个文件进行修改时，重新编译源文件时，是全部重新编译还是编译部分？
是对修改源文件进行编译，然后在与之前的源文件编译过的文件进行链接。形成新的可执行文件。
因为会对时间进行一个对比，我们之间在VS上编译代码时，会发现我们解决了问题，但编译执行文件时依旧还是按照之前的程序执行，这就是因为VS识别文件不及时或者是没识别出来，还以为你的文件没有修改，所以他也没有对你的程序重新编译
5.认识一下时间
5.1Modeify和Change两个时间有什么区别
我们发现文件有两个修改时间：Modify和Change
文件 = 内容 + 属性
那么：Modify对应的是内容修改时间
而：Change对应的是属性修改时间
那么文件内容好理解，那么什么事文件属性呢？其实，我们利用命令ll查看到的就是文件属性。
同样，我们发现文件属性里有文件大小。文件内容的改变容易引起文件大小的改变。
所以：Modify的改变往往伴随着Change的改变；而Change的改变往往是单一的。
5.2 文件的Access时间（访问文件时间）特殊的时间更新策略
因为发现我们在使用Linux操作系统时，我们访问文件的频率是非常高的，如果一访问一个文件就去修改的磁盘内文件的属性，这会导致磁盘效率比较紧张，为了提高效率，所以Linux就设定了当到达一定访问次数或者访问时间后再去修改访问文件时间
5.3 关于可执行程序的文件时间和源文件的文件时间该对比哪个文件时间比较合适呢？
我们这里发现 即使Change Time 已经被修改，但是mybin.c 依旧无法被被编译。
所以，可执行程序的文件时间和源文件的文件时间对比的不是Change Time。
所以，可执行程序的文件时间和源文件的文件时间对比的是Modify Time
6.补充语法
.PHONY:目标文件
这样添加了.PHONY这样就可以让mybin总是被执行。
我们发现其实上对比时间的工作是有make和makefile来做的，gcc并不关心。所以，当添加了这个伪目标后，make和makefile就默认不会对这个文件继续进行时间对比的操作。
我们发现make clean即使没有.PHONY照样能够重复执行，那是因为 原本比较的是源文件和目标文件，但是clean连源文件和目标文件都不清晰，所以，clean也是总是被执行。
惯用做法
我们一般吧伪目标设定为clean，来保证clean可以每次都被执行。
对于编译器来说，还是尊重编译器的规则，毕竟他的规则非常正确。
如果，项目比较大时，每个源文件都要重新编译的话，太浪费时间了，效率低下。
关于make和makefile的语法推导
就想递归似的，依赖关系先入栈，再执行后入栈的依赖关系的依赖方法。
扫一扫
3430
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
