wordpress插件 osgi北京seo工程师
前言
如题可知,make/Makefile为在Linux下的项目自动化构建工具;
在上一篇文章『Linux - gcc / g++』c程序翻译过程 中讲解了C/C++程序的翻译过程;
而make/Makefile即可以看成,是Makefile在使用gcc/g++使在Linux环境下能够更好的高效率的进行项目构建;
在此之前首先要对make/Makefile进行说明:
- make
首先,make是一条命令,也可以说通过make命令可以解析Makefile文件; - Makefile
而Makefile是一个文件,是用来告诉make命令该如何编译工程,生成可执行程序;
当然,必须要现有Makefile文件才能使用make命令解析Makefile文件从而达到自动化构建项目的作用;
编写Makefile
假设存在一个.cpp文件,代码为:
#include<iostream>
//测试代码 用来测试make
int main()
{std::cout<<"it's a test file!"<<std::endl;
}
若是需要使该文件生成对应可执行文件即可使用命令:
g++ -o mytest test.cpp #将程序进行翻译直到链接结束生成可执行程序为止
而现在需要一个对应的Makefile文件来使其可以自动化构建项目;
先用命令touch来建立一个Makefile文件;
touch Makefile
建立完Makefile文件后使用vim进行编辑;
mytest:test.cpp g++ -o mytest test.cpp .PHONY:clean
clean: rm -rf mytest
拥有该Makefile文件后即可使用make命令对Makefile文件进行解析从而达到构建项目的的效果;
当然对应的也可以进行项目的清理;
由于Makefile文件中拥有一个用来清理项目的伪目标clean,在调用时使用命令:
make clean
即可对项目进行清理,当然会根据我们在Makefile文件中所指定的规则进行清理;
既然如此那么在Makefile文件中的每一行分别是什么?
由上到下每一行依次分别为:
- 第1行 - 依赖关系
mytest:test.cpp
#以冒号:作为分界,冒号的左侧为目标文件,冒号的右侧为依赖文件列表;
目标文件即为目标生成的文件,依赖文件列表即为所生成的文件依赖的文件,在这里可以表示为,这里的可执行文件mytest是由test.cpp翻译生成的,所以依赖于test.cpp文件;
同时在Makefiel的语法中,目标文件必须在顶格,且必须跟冒号:
- 第2行 - 依赖方法
g++ -o mytest test.cpp #依赖方法 该行必须紧挨着第一行,不能空行,且该行必须以table键开头
#可以理解为,生成mytest可执行程序时需要依靠命令g++ -o mytest test.cpp
同时在语法中,依赖方法所在行前必须有其他依赖方法或者是紧跟依赖关系行;
- 第4行 - .PHONY伪目标修饰
.PHONY:clean
该关键字.PHONY的作用即为修饰 : 后的目标文件为伪目标;
- 第5,6行
与第1,2行相同,不同的是在这里的依赖关系中,目标文件clean不需要依赖文件;
此处是用作清除,而在大多数的开源中所使用的清除都是用的clean;
也可以使用其他名;
clean: #该行与第一行相同,冒号左边为目标文件,右侧为依赖文件列表,不同的是该目标文件不需要依赖文件rm -rf mytest #依赖方法#该处的四五六行是用来清理的#有了四五六行即可以在Makefile文件所对应的文件夹中使用 make clean 进行对应文件的清理;
在执行make命令时 , 默认使用Makefile文件中的第一对依赖关系与依赖方法;(自顶向下扫描会形成第一个遇到的目标文件)
此处若是将 形成对应文件的依赖关系依赖方法 与 清理对应文件的依赖关系依赖方法 调换再执行make命令时;
首先将会执行 清理对应文件的依赖关系与方法 ;
.PHONY:所修饰的伪目标
在很多教材之中，对于伪目标的描述是这样的：“伪目标是总是被执行的”；
但是这里的总是被执行是什么意思？
若是多次进行make，则只有第一次会被执行；
而后面的几次将不会被执行；
而若是执行make clean时则不同；
每一次的make clean都会被执行；
这个原因就是因为clean被修饰成为了伪目标；
这里的 “ 伪目标总是被执行的 ” 这句话的意思即为，伪目标总是会根据依赖关系，执行此依赖方法；
在一般的习惯中，都会将clean设置为伪目标；
若是希望其他的目标文件同样可以总是被执行，可以将其修饰为伪目标；
编译器和Makefile是如何得知可执行程序是最新的
在我们make了一次之后,在没有修改源文件之前再次make时都会显示一个类似于 “当前的可执行程序为最新” 的提示;
但若是在该处修改了源文件，并再次进行make指令时又会重新生成相应的可执行程序；
既然如此，那么编译器或者Makefile是如何知道当前可执行程序是最新的呢？
在Linux中有一条为 stat 的命令,该命令可以查看一个文件中最重要的三个时间；
stat mytest
这三个时间分别为:
| 时间 | 内容 |
|---|---|
| （Access）访问时间 | 访问文件的修改已经在Linux内核中进行了改动，在原先的Linux版本中，对于文件的访问（cat，ls等操作）都是会进行修改的，而这种，由于对文件的访问是一个高频操作；而文件是存在磁盘当中，若是每次访问文件都对Access进行改动的话，说明这个高频操作将会大量的去对磁盘进行访问，而高频的磁盘访问定会降低访问程序的效率；故在Linux的内核中修改为，当对文件进行一段时间的访问（累计）过后才会修改该属性； |
| （Modify）修改(内容)时间 | 文件内容的修改时间； |
| （Change）修改(属性)时间 | 文件属性的修改时间 |
回归正题，为什么编译器和Makefile能够知道当前的可执行程序是最新的；
真正来说，在使用make指令来对Makefile进行操作时，若是当前已经拥有一个可执行程序；
则会将各个源文件与当前的可执行程序进行Modify时间的比较，若是当前可执行文件的修改时间晚于各个源文件，则代表当前可执行程序为最新；
多文件使用Makefile
假设当前有三个文件（不包括Makefile文件），分别为两个源文件(test.cpp main.cpp)与一个头文件(test.hpp)；
若是用指令编译则为:
g++ main.cpp test.cpp -o test
在Makefile文件中也可以使用该指令；
mytest:test.cpp main.cppg++ main.cpp test.cpp -o mytest.PHONY:clean #修饰为伪目标
clean:rm -f mytest
但是一般多文件进行Makefile操作时习惯使用.o进行连接；
mytest:test.o main.o #所生成的文件依赖test.o与main.o文件g++ test.o main.o -o mytest #需要生成mytest文件需要对两个.o文件进行链接（头文件被#include展开后可以不用再管）main.o:main.cpp #make首先会看到上面第一对依赖关系与依赖方法，但是上面的依赖文件列表并没有.o文件 将会继续往下找第二对依赖关系与方法g++ -c main.cpp -o main.o
test.o:test.cpp #以此类推g++ -c test.cpp -o test.o.PHONY:clean
clean:rm -f *.o mytest #此处删除所有的.o文件同时删除mytest文件