目录
什么是make/Makefile
以往在Linux下写程序,每次改代码,我们都需要进行重新编译,如果是单一文件还好,假如一个工程中的源文件有许多,我们不可能去一个一个文件得使用gcc
所以makefile的功能是自动化编译,一旦编译好,只需要一个make
命令,整个工程完全自动编译,极大得提高软件开发效率
下面我们通过一个简单的例子来学习Makefile
make/Makefile的一个简单的例子
要先明白什么是make
,什么是Makefile
:
make
是一条指令
Makefile
是当前目录下的文件
首先,要在源文件同级目录下建立一个名为makefile/Makefile文件(m是否大小写都可以)
然后在makefile
中写入:
bash
mycode:mycode.c
gcc -o mycode mycode.c
mycode:mycode.c
是依赖关系,意思是mycode
依赖于mycode.c
文件,将mycode.c
编译成mycode
gcc -o mycode mycode.c
是依赖方法,光有依赖关系还不够,还要有依赖方法:如何把mycode.c
形成mycode
并且要注意:依赖方法前面必须是一个tab
现在一个最简单的Makefile就写好了,下面运行来试一下
目前目录下没有名为mycode
的可执行文件,然后输入命令make
,接着ll
发现,新增了名为mycode
的可执行文件
并且我们还可以看到执行make
命令后,会打印出执行的依赖方法gcc -o mycode mycode.c
make
完一次后,再make
就不允许了
所以,以后就不需要再手动进行编译了,配置好makefile
文件后,命令行输入make
指令,会自动地在当前目录下寻找makefile
文件,然后通过里面的依赖关系和依赖方法,执行对应的依赖方法
既要支持编译,也要支持清理,不然如果一个项目中文件过多,一个一个得删除可执行文件也是十分麻烦的
bash
mycode:mycode.c
gcc -o mycode mycode.c
clean:
rm -f mycode
这里的clean
是自定义的依赖关系,名字随便取,冒号后面为空,表示clean
不依赖任何文件,随时都可以执行对应的依赖方法
输入make clean
会执行依赖方法
问题1
我们现在把makefile
写得复杂一些
bash
mycode:mycode.o
gcc -o mycode mycode.o
mycode.o:mycode.s
gcc -c mycode.s -o mycode.o
mycode.s:mycode.i
gcc -S mycode.i -o mycode.s
mycode.i:mycode.c
gcc -E mycode.c -o mycode.i
clean:
rm -f mycode mycode.o mycode.s mycode.i
然后输入make
,我们发现执行得顺序与我们在makefile
中的顺序不一样
原因是:
make
指令进行扫描时,优先根据依赖关系,所有依赖关系的文件列表在当前目录下是否存在,若不村在,makefile会类似递归似的形成依赖文件,最后根据依赖文件形成结果文件
mycode
依赖mycode.o
,make
发现当前目录下没有mycode.o
文件,然后mycode.o
有自己的依赖关系,依赖mycode.s
文件- 但是当前目录下没有
mycode.s
文件,mycode.s
有自己的依赖关系,它依赖于mycode.i
- 但是当前目录下没有
mycode.i
文件,mycode.i
有自己的依赖关系,它依赖于mycode.c
mycode.c
是有的,然后mycode.c
生成mycode.i
,mycode.i
生成mycode.s
,mycode.s
生成mycode.o
,最后mycode.o
变为mycode
,得到最终的目标文件
这个过程类似于栈和递归
所以在makefile中,是乱序也不影响
问题2
前面在使用下面这个makefile文件时,为什么输入make
会执行mycode:mycode.c
这个依赖关系和其对应的依赖方法,而想要清理就需要输入make clean
命令?
是因为make
会自顶向下扫描makefile
,将第一个依赖关系的目标文件充当make
的默认动作
其实输入make mycode
也会达到和make
相同的效果
下面将clean和mycode调换一下位置;
bash
clean:
rm -f mycode mycode.o mycode.s mycode.i
mycode:mycode.o
gcc -o mycode mycode.o
mycode.o:mycode.s
gcc -c mycode.s -o mycode.o
mycode.s:mycode.i
gcc -S mycode.i -o mycode.s
mycode.i:mycode.c
gcc -E mycode.c -o mycode.i
那么make
就默认执行清理任务,想生成mycode
就需要手动输入make mycode
问题3
前面我们可以知道,make
一次后,不能够进行第二次make
,是为什么呢?
原因:一个源文件被make
一次后,如果源文件没有被修改,make
是不允许重新编译的
目的:主要是为了提高编译效率
是如何做到的呢?
先有源文件,后又对应的可执行文件,所以一般而言,源文件的最近修改时间是一定要老于可执行文件的最近修改时间
如果修改了源文件,目前还有上一版本源文件生成的可执行文件
所以此时,源文件的最近修改时间就新于可执行文件的时间
所以只需要对比可执行文件和源文件的最近修改时间
如果可执行文件新于源文件,不需要重新编译
如果源文件新于可执行文件,需要重新编译
一般而言,这两个文件的最近修改时间是不会相同的
这里对于时间的比较,比较的是时间戳
下面可以验证一下:
stat
命令可以查看文件修改时间
这里会显示三个时间:Access
,Modify
,Change
Access
是访问时间
Modify
是对文件内容修改时间
Change
是对文件属性修改时间
执行touch + 一个已经存在的文件
,会将3个时间都修改,加上选项-a
,-m
,-c
是修改单个时间
下面我们来验证一下:
先make
一次,再make
一次,发现不允许make
接着修改mycode.c
的时间,再make
一次,发现就被允许了
但是如果想每次的make
都被允许,不管源文件和可执行文件的时间。可以使用.PHONY
bash
.PHONY:mycode
mycode:mycode.o
gcc -o mycode mycode.o
mycode.o:mycode.s
gcc -c mycode.s -o mycode.o
mycode.s:mycode.i
gcc -S mycode.i -o mycode.s
mycode.i:mycode.c
gcc -E mycode.c -o mycode.i
clean:
rm -f mycode mycode.o mycode.s mycode.i
.PHONY
是伪目标,用它修饰mycode
,就会让mycode
的依赖方法总是要重新编译
单一一般不建议这么用,不建议把目标文件用伪目标修饰
一般建议用.PHONY
修饰清理:
bash
mycode:mycode.c
gcc -o mycode mycode.c
.PHONY:clean
clean:
rm -f mycode
特殊符号
$@
,替代依赖关系中,冒号左侧的内容
$^
,替代依赖关系中,冒号右侧的内容
bash
mycode:mycode.c
gcc -o $@ $^
.PHONY:clean
clean:
rm -f mycode
每次执行依赖方法后,都会将依赖方法打印到屏幕上,如果不想要打印,可以在依赖方法前加@
bash
mycode:mycode.c
@gcc -o $@ $^
.PHONY:clean
clean:
@rm -f mycode
执行make
和make clean
后,什么都没有打印: