您现在的位置是:首页 >技术交流 >makefile的简介与使用网站首页技术交流
makefile的简介与使用
makefile用来做什么
通常一个大型程序是由多个程序模块组成的,按照其功能划分,模块文件会分布在不同的目录中,模块与模块之间也会存在依赖关系,大多数情况下,我们编写程序只是修改了部分文件,肯定不是同时更新所有文件,按理说只要重新编译那些修改过的文件,用不着编译全部文件,如果编译全部文件的话,对于那些大型工程时间成本还是非常高的,比如Linux内核这种几千万行代码的东西。
那么我们的问题就是自动针对那些有过改动的文件进行编译,这个问题分为两个小问题
(1) 目标文件依赖那些文件
(2) 依赖的文件是否更新
对于第一个问题,如果只依靠人工来维护文件间的依赖关系,当程序规模不大还好,当程序规模变得很大时,那些依赖会让人发狂。那时候我宁愿直接编译所有文件。
好在万能的Linux提供了make命令,它可以帮助我们自动找出变更的文件,并根据依赖关系,找出受变更文件影响的其他相关文件,然后对这些文件按照规则进行单独处理,此处的规则一般都是指编译,如调用gcc,但也可以是删除文件等其他行为。
上述的规则、依赖关系是定义在一个名叫makefile的文件中的,这两哥们儿的使命主要就是:发现某个文件更新后,只编译该文件和受该文件影响的相关文件,其他不受影响的文件不重新编译,从而提高了编译效率。
这里给大家强调一下,make和makefile并不是用来编译程序的,编译程序的还是gcc,他们哥俩只是找出那些文件需要更新,然后调用其他命令对这些文件进行处理,大多是情况下是调用gcc或者nasm进行编译,也有可能是rm删除文件,当然也可以在命令规则中执行其他命令,这是您自己决定的。
makefile基本语法
目标文件:依赖文件
[Tab]命令
makefile基本语法包括三部分,这三部分加在一起称为一组规则,下面解释下各部分的意义。
目标文件: 目标文件是指此规则中想要生成的文件,可以是.o结尾的目标文件,也可以是可执行文件,也可以是个伪目标,后面会介绍伪目标。
依赖文件: 依赖文件是指要生成此规则中的目标文件,需要哪些文件。通常依赖文件不是1个,所以此处是个依赖文件的列表。
命令: 命令是指此规则中要执行的动作,这些动作是指各种shell命令,命令可以有多个,但一个命令要单独占用一行,在行首必须用Tab开头,这是make规定的用法。
以上规则的意义是:要想生成目标文件,需要提前准备好依赖文件,如果依赖文件列表中任意一个文件比目标文件新,就去执行规则中的命令。
make程序如何判断文件有过更新
在Linux中,文件分为属性和数据两部分,每个文件有三种时间,分别用于记录与文件属性和文件数据相关的时间,这三个时间分别是atime、mtime、ctime。
atime,即access time,表示访问文件数据部分时间,每次读取文件数据部分时就会更新atime,强调下,是读取文件数据(内容)时改变atime,比如cat或less命令查看文件就可以更新atime,而ls命令则不会。
ctime,即change time,表示文件属性或数据的改变时间,每当文件的属性或数据被修改时,就会更新ctime,也就是说ctime同时跟踪文件属性和文件数据变化的时间。
mtime,即modify time,表示文件数据部分的修改时间,每次文件的数据被修改时就会更新mtime。在上面说过啦,ctime也跟踪数据变化时间,所以,当文件数据被修改时,mtime和ctime一同更新。
在Linux中查看这三个时间可以用 stat
命令。
lovess@Lyajpunov:~$ stat a.c
File: a.c
Size: 119 Blocks: 0 IO Block: 4096 regular file
Device: 2h/2d Inode: 5629499536446330 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ lovess) Gid: ( 1000/ lovess)
Access: 2023-03-20 20:59:05.709967700 +0800
Modify: 2023-03-20 20:58:41.805699100 +0800
Change: 2023-03-20 20:58:41.806695800 +0800
Birth: -
对于文件来说,我们更加关注它的数据部分,所以只要make程序分别获取依赖文件和目标文件的mtime,对比依赖文件的mtime是否比目标文件的mtime新,就知道是否要执行规则中的命令。这里的命令并非必须是编译命令,
举个例子
1:2
echo "OKKKKKKKKKK"
我们用touch命令先生成1和2这两个文件,然后make,就可以在终端得到字符串
echo "OKKKKKKKKKK"
OKKKKKKKKKK
但是这里把我们的命令也输出了,只要在命令前加@,就可以不输出命令
1:2
@echo "OKKKKKKKKKK"
通过这个简单的例子,我们也能知道,make和makefile不是专门用来编译文件的,他只是执行规则中的命令。
makefile的文件名也并非固定,可以在执行make时用-f参数来指定。如果未用-f指定,默认情况下,make会先去找名为GNUmakefile的文件,若该文件不存在,再去找名为makefile的文件,若makefile也不存在,最后去找名为Makefile的文件
跳到目标处执行
make中有很多目标时,我们可以用目标名称作为make的参数,采用 “make 目标名称” 的方式,单独执行目标名称处规则。注意,这种方式只会执行目标名称处的规则,之后就退出了,后面即使存在其他的目标也不会再执行。
举个例子
t1:1
@echo "t1"
t2:1
@echo "t2"
执行
lovess@Lyajpunov:~$ make t1
t1
lovess@Lyajpunov:~$ make t2
t2
当make后面没有目标名称做参数时,make会在makefile中第一个出现的目标处开始执行。
一般情况下,命令能否执行是要看所依赖文件的mtime是否比目标文件要新。如果依赖文件的mtime比目标文件旧的话,说明目标文件已经是最新的,根本不需要更新,所以按理说,此种情况下规则中的命令是不会执行的,事实也正是如此。
伪目标
通过上面的例子您看到了,规则中的命令并不总是被执行,有时候我们并不关心是否产生真实的目标文件,我们只希望make不要考虑mtime,而是总能去执行一些命令。
对于这个需求还是有办法的,make规定,当规则中不存在依赖文件时,这个目标文件名就称为—伪目标。
伪目标,顾名思义,也就是不产生真实的目标文件,所以当然也就不需要依赖文件了。于是,伪目标所在的规则就变成了纯粹地执行命令,只要给make指定该伪目标名做参数,就能让伪目标规则中的命令直接执行。
举个例子
all:
@echo "test ok"
由于makefile中仅有这一个目标all,所以如果此时执行make all或make,程序只会输出test ok。
注意,伪目标不能和真实目标文件同名,否则就失去伪目标的意义了,为了避免伪目标和真实目标文件同名的情况,可以用关键字“.PHONY”来修饰伪目标,格式为“.PHONY:伪目标名”,这样不管与伪目标同名的文件是否存在,make照样执行伪目标处的命令。
通常需要显式用.PHONY修饰伪目标的场合是删除编译过程中的.o文件,这是为了避免因旧的.o文件已存在而影响编译。如果您在Linux下有过编译源码的经验,就会了解make clean的作用了,通常clean就是伪目标,用来删除编译过程中的.o文件,如:
.PHONY:clean
clean:
rm ./build/*.o
伪目标的命名并没有固定的规则,用户可以按照自己的意愿定义成自己喜欢的名字。不过,由于makefile已经流传很广泛了,对于伪目标的命名,业界内已经有了一些约定俗成的规则,大伙儿把类似功能的伪目标定义成了同一个名字。比如上面提到的clean,这个伪目标名称也是大伙儿公认的,它的功能通常就是清空目标文件,当然了,相应的命令部分还得是rm等清除相关的命令。这里再列举一些其他公认的伪目标名。
伪目标名称 | 功能描述 |
---|---|
all | 通常用来完成所有模块的编译工作,类似于rebuild all |
clean | 清空编译完成所有的目标文件,一般用rm来实现 |
dist | 通常用于将打包成tar的文件再压缩 |
install | 将编译好的程序复制到安装目录下,此目录是在执行configure脚本通过–prefix参数配置的 |
printf | 打印已经发生改变的文件 |
tar | 用于将文件打包成tar文件,也就是所谓的归档 |
test | 测试makefile流程 |
make递推推导
在makefile中的目标,是以递归的方式逐层向上查找目标的,就好像是从迷宫的出口往回找来时的路一样,由果寻因,逐个向上推导。这一点尤其体现在多个目标相互依赖的情况下。
举个例子,两个文件有依赖关系
lovess@Lyajpunov:~$ cat -n test1.c
1 void my_print(char *);
2
3 int main(){
4 my_print("hello makefile!");
5 }
lovess@Lyajpunov:~$ cat -n test2.c
1 #include <stdio.h>
2
3 void my_print(char *str) {
4 printf(str);
5 }
我们试着把这两个文件编译成test.bin
test2.o:test2.c
gcc -c -o test2.o test2.c
test1.o:test1.c
gcc -c -o test1.o test1.c
test.bin:test1.o test2.o
gcc -o test.bin test1.o test2.o
all:test.bin
@echo "compile done"
执行命令
make all
就可以生成最终的执行程序 test.bin
我们关注的是这里的递推流程
(1)make未找到文件GNUmakefile,便继续找文件makefile,找到后,根据命令的参数all,从文件中找到all所在的规则。
(2)make发现all的依赖文件test.bin不存在,于是就去找以test.bin为目标文件的规则。
(3)在第5行终于找到了test.bin的规则,但make发现,test.bin的依赖文件test1.o和test2.o都不存在,于是先去找以test1.o为目标文件的规则。
(4)第3行找到了生成test1.o的规则,但它的依赖文件是test1.c,由于test1.o本身不存在,所以不用再查看test1.c的mtime,直接执行此规则的命令。
(5)生成test1.o后,执行流程返回到test.bin所在的规则,即第5行,此时make发现test2.o也不存在,于是继续递归查找目标test2.o。
(6)在第1行发现test2.o所在的规则,由于test2.o本身不存在,也不再检查其所依赖文件test2.c的mtime,直接执行规则中的编译命令
(7)生成test2.o后,此时执行流程又回到了第5行,make发现两个依赖文件test1.o和test2.o都准备齐了,于是执行本规则的命令,即第6行的gcc -o test.bin test1.o test2.o,将这两个目标文件生成可执行文件test.bin。
(8)test.bin终于生成了,此时回到了第2步目标all所在的规则,于是执行所在规则中的命令@echo “compile done”,打印字符串表示编译完成。
虽然all被当作了真实目标文件来处理,但我们给出的命令并不是为了生成它,所以它同伪目标的作用类似。
自定义变量与系统变量
makefile既然可称为编程,它必然就具备程序语言的必须的基本功能,比如,可以在makefile中定义变量。很遗憾的是makefile还没有编程语言的图灵完备性。
变量定义的格式:变量名=值(字符串),多个值之间用空格分开。make程序在处理时会用空格将值打散,然后遍历每一个值。另外,值仅支持字符串类型,即使是数字也被当作字符串来处理。
变量引用的格式:$(变量名)。这样,每次引用变量时,变量名就会被其值(字符串)替换。
注意,虽然变量的值会被当作字符串类型处理,但不能将其用双引号或单引号括起来,否则双引号或单引号也会被当作变量值的一部分。比如var = ‘file.c’,var的值并不是file1.c,而是’file.c’。当引用变量$(var) 做依赖文件时,make会去找名为’file.c’的目标,而不是file.c。
举个例子
test2.o:test2.c
gcc -c -o test2.o test2.c
test1.o:test1.c
gcc -c -o test1.o test1.c
objfiles = test1.o test2.o
test.bin:$(objfiles)
gcc -o test.bin $(objfiles)
all:test.bin
@echo "compile done"
效果和上文中定义的效果是一样的。
除了用户自定义的变量外,make还自行定义了一些系统级的变量,按其用途可分为命令相关的变量及参数相关的变量。见下表
变量名 | 描述 |
---|---|
AR | 打包程序,默认是“ar” |
AS | 汇编语言编译器,默认是“as” |
CC | C语言编译器,默认是“cc” |
CXX | C++语言编译器,默认是“g++” |
CPP | C预处理器,默认是“$(CC) –E”,如gcc -E |
FC | Fortran的编译器和预处理器,Ratfor的编译器,默认是“f77” |
GET | 从SCCS文件中提取文件程序,默认是“get” |
PC | Pascal语言编译器,默认是“pc” |
MAKEINFO | 将texinfo文件转换为info文件,默认是“makeinfo” |
RM | 删除命令,默认是“rm -f” |
TEX | 从TeX源文件中创建TexDVI文件的程序,默认是“tex” |
WEAVE | 将We b转换为TeX的程序,默认是“weave” |
YACC | 处理C程序的Yacc词法分析器,默认是“yacc” |
YACCR | 处理Ratfor程序的Yacc词法分析器,默认是“yacc -r” |
隐含规则
在编写规则时,若一行写不下,可以在行尾添加反斜杠字符’’,这样下一行的内容便被认为是同一行,其实这是很多编译器和解释器都支持的功能,不仅是make才这样。
makefile中另一个必须的功能是注释,如同shell脚本一样,makefile中用#来单行注释,只要各行第一个非空字符(除空格、tab)是’#’,本行内容便被注释了。如果在行尾是反斜杠字符’’,这表示下一行也应被处理为当前行,所以,连同下一行也被注释掉。
#test2.o:test2.c
# gcc -c -o test2.o test2.c
#test1.o:test1.c
# gcc -c -o test1.o test1.c
objfiles = test1.o test2.o
test.bin:$(objfiles)
gcc -o test.bin $(objfiles)
all:test.bin
@echo "compile done"
但是我们执行这个程序
lovess@Lyajpunov:~$ make all
cc -c -o test1.o test1.c
cc -c -o test2.o test2.c
gcc -o test.bin test1.o test2.o
compile done
这两个文件依然被编译了,使用的是cc命令,makefile中的编译命令是gcc,此处输出的编译命令是cc,所以makefile中的gcc真的是注释掉了,这一点请大伙儿放心。另外,cc其实就是gcc的软链接,这两个是同一个程序,都是指向/usr/bin/gcc。
对于一些使用频率非常高的规则,make 把它们当成是默认的,不需要显式地写出来,当用户未在makefile中显式定义规则时,将默认使用隐含规则进行推导。
隐含规则对于不同的程序语言是不同的,是根据一般的依赖关系来自动推导,属于重建目标文件的通用方法。
针对不同的编程语言依赖关系,make程序通过除扩展名之外的文件名部分,再根据隐含规则,可以推导出最终的可执行文件。也就是说,若想通过隐含规则自动推导生成目标,存在于文件系统上的文件,除扩展名之外的文件名部分必须相同。比如x.o的C源文件必须名为x.c,这样通过隐含规则才能成功生成x.o。
下面列举一些常见语言的隐含规则
-
C程序
“x.o”的生成依赖于“x.c”,生成x.o的命令为:
$(CC) -c $(CPPFLAGS) $(CFLAGS)
-
C++程序
“x.o”的生成依赖于“x.cc”或者“x.C”,生成x.o的命令为:
$(CXX) -c $(CPPFLAGS) $(CFLAGS)
自动化变量
make还支持一种自动化变量,此变量代表一组文件名,无论是目标文件名,还是依赖文件名,此变量值的范围属于这组文件名集合,也就是说,自动化变量相当于对文件名集合循环遍历一遍。对于不同的文件名集合,有不同的自动化变量名,下面列举一些。
$@,表示规则中的目标文件名集合,如果存在多个目标文件,$@则表示其中每一个文件名
$<,表示规则中依赖文件中的第1个文件。助记,‘<’很像是集合的最左边,也就是第1个。
$,表示规则中所有依赖文件的集合,如果集合中有重复的文件,$会自动去重。助记,’^’很像从上往下罩的动作,能罩住很大的范围,所以称为集合
$?,表示规则中,所有比目标文件 mtime 更新的依赖文件集合。助记,’?’表示疑问,make最大的疑问就是依赖文件的mtime是否比目标文件的mtime要新。
举个例子
objfiles = test1.o test2.o
test.bin:$(objfiles)
gcc -o $@ $^
all:test.bin
@echo "compile done"
我们在第3行用$@代替了test.bin,用$^代替了所有依赖文件。
模式规则
模式,即pattern,其实就是指字符串模(mú,二声)子,正则表达式中用此概念表示字符或字符串匹配,把符合此模子的字符串找出来,make中也支持这种字符串匹配用法。
%用来匹配任意多个非空字符。比如%.o代表所有以.o为结尾的文件,g%s.o是以字符g开头的所有以.o为结尾的文件,make会拿这个字符串模式去文件系统上查找文件,默认为当前路径下。
%通常用在规则中的目标文件中,以用来匹配所有目标文件,%也可以用在规则中的依赖文件中,因为目标文件才是要生成的文件,所以当%用在依赖文件中时,其所匹配的文件名要以目标文件为准。拿%.o:%.c为例,假如用%.o匹配到了目标文件a.o和b.o,那么依赖文件中的%.c将分别匹配到a.c和b.c。
举个例子
%.o:%.c
gcc -c -o $@ $^
objfiles = test1.o test2.o
test.bin:$(objfiles)
gcc -o $@ $^
all:test.bin
@echo "compile done"
但是这样会不会有别的风险呢,比如我们文件目录下有别的.c文件,会不会吧这个c文件也编译了呢,答案是不会的,因为递推是从test.bin开始的,推导到上面只会推导出 test1.c
和 test2.c
,不会涉及到其他的c文件了,所以其他的C文件也不会被编译。