Makefile带来的好处就是“自动化编译,一旦写好Makefile文件,执行make(命令工具)整个工程就完成编译。
程序编译的一些规范和方法,一般来说,无论是C还是C++,首先要把源文件编译成中间代码文件,在Windows下也就是 .obj 文件,UNIX下是 .o 文件,即 Object File,这个动作叫做编译(compile)。然后再把大量的Object File合成执行文件,这个动作叫作链接(link)。
编译时,编译器需要的是语法的正确,函数与变量的声明的正确。对于后者,通常是你需要告诉编译器头文件的所在位置(头文件中应该只是声明,而定义应该放在C/C++文件中),只要所有的语法正确,编译器就可以编译出中间目标文件。一般来说,每个源文件都应该对应于一个中间目标文件(O文件或是OBJ文件)。
链接时,主要是链接函数和全局变量,所以,我们可以使用这些中间目标文件(O文件或是OBJ文件)来链接我们的应用程序。链接器并不管函数所在的源文件,只管函数的中间目标文件(Object File),在大多数时候,由于源文件太多,编译生成的中间目标文件太多,而在链接时需要明显地指出中间目标文件名,这对于编译很不方便,所以,我们要给中间目标文件打个包,在Windows下这种包叫“库文件”(Library File),也就是 .lib 文件,在UNIX下,是Archive File,也就是 .a 文件。
make命令执行时,需要一个 Makefile 文件,以告诉make命令需要怎么样的去编译和链接程序。
首先,我们用一个示例来说明Makefile的书写规则。以便给大家一个感兴认识。这个示例来源于GNU的make使用手册,在这个示例中,我们的工程有8个C文件,和3个头文件,我们要写一个Makefile来告诉make命令如何编译和链接这几个文件。我们的规则是:
1.如果这个工程没有编译过,那么我们的所有C文件都要编译并被链接。
2.如果这个工程的某几个C文件被修改,那么我们只编译被修改的C文件,并链接目标程序。
3.如果这个工程的头文件被改变了,那么我们需要编译引用了这几个头文件的C文件,并链接目标程序。
在定义好依赖关系后,后续的那一行定义了如何生成目标文件的操作系统命令,一定要以一个Tab键作为开头。记住,make并不管命令是怎么工作的,他只管执行所定义的命令。make会比较targets文件和prerequisites文件的修改日期,如果prerequisites文件的日期要比targets文件的日期要新,或者target不存在的话,那么,make就会执行后续定义的命令。
这里要说明一点的是,clean不是一个文件,它只不过是一个动作名字,有点像C语言中的lable一样,其冒号后什么也没有,那么,make就不会自动去找文件的依赖性,也就不会自动执行其后所定义的命令。要执行其后的命令,就要在make命令后明显得指出这个lable的名字。这样的方法非常有用,我们可以在一个makefile中定义不用的编译或是和编译无关的命令,比如程序的打包,程序的备份,等等。
make是如何工作的:
在默认的方式下,也就是我们只输入make命令。那么,
1 make会在当前目录下找名字叫“Makefile”或“makefile”的文件。
2 如果找到,它会找文件中的第一个目标文件(target),在下面的例
子中,他会到“test”这个文件,并把这个文件作为最终的目标文件。
3 如果test文件不存在,或是test所依赖的后面的 .o 文件的文件修改
时间要比test这个文件新,那么,他就会执行后面所定义的命令来生
成test这个文件。
4 如果test所依赖的.o文件也存在,那么make会在当前文件中找目标
为.o文件的依赖性,如果找到则再根据那一个规则生成.o文件(这
有点像一个堆栈的过程)
5 当然,你的C文件和H文件是存在的啦,于是make会生成 .o文件,
然后再用 .o文件声明make的终极任务,也就是执行文件test了。
这就是整个make的依赖性,make会一层又一层地去找文件的依赖关系,直到最终编译出第一个目标文件。在找寻的过程中,如果出现错误,比如最后被依赖的文件找不到,那么make就会直接退出,并报错,而对于所定义的命令的错误,或是编译不成功,make根本不理。make只管文件的依赖性,即,如果在我找了依赖关系之后,冒号后面的文件还是不在,那么对不起,我就不工作啦。
通过上述分析,我们知道,像clean这种,没有被第一个目标文件直接或间接关联,那么它后面所定义的命令将不会被自动执行,不过,我们可以显示要make执行。即命令——“make clean”,以此来清除所有的目标文件,以便重编译。于是在我们编程中,如果这个工程已被编译过了,当我们修改了其中一个源文件,比如test.c,那么根据我们的依赖性,我们的目标test.o会被重编译(也就是在这个依性关系后面所定义的命令),于是test.o的文件也是最新的啦,于是test.o的文件修改时间要比test要新,所以test也会被重新链接了(详见test目标文件后定义的命令)。而如果我们改了“command.h”,那么,kdb.o、command.o和test.o都会被重编译,并且,test会被重链接。
每个Makefile中都应该写一个清空目标文件(.o和执行文件)的规则,这不仅便于
重编译,也很利于保持文件的清洁。这是一个“修养”一般的风格都是:
1
2
|
clean:
rm edit $(objects)
|
更为稳健的做法是:
1
2
3
|
.PHONY : clean
clean :
-rm edit $(objects)
|
前面说过,.PHONY意思表示clean是一个“伪目标”,而在rm命令前面加了一个小减号的意思就是,也许某些文件出现问题,但不要管,继续做后面的事。当然,clean的规则不要放在文件的开头,不然,这就会变成make的默认目标,相信谁也不愿意这样。不成文的规矩是——“clean从来都是放在文件的后”。
1.如果make执行时,有“-I”或“--include-dir”参数,那么make就会在这个参数所指定的
目录下去寻找。
2.如果目录/include(一般是:/usr/local/bin或/usr/include)存在的话,make也会去
找。
伪目标一般没有依赖的文件。但是,我们也可以为伪目标指定所依赖的文件。伪目标同样可以作为“默认目标”,只要将其放在第一个。一个示例就是,如果你的Makefile需要一口气生成若干个可执行文件,但你只想简单地敲一个make完事,并且,所有的目标文件都写在一个Makefile中,那么你可以使用“伪目标”这个特性:
1
2
3
4
5
6
7
8
9
10
11
|
all : prog1 prog2 prog3
.PHONY : all
prog1 : prog1.o utils.o
cc -o prog1 prog1.o utils.o
prog2 : prog2.o
cc -o prog2 prog2.o
prog3 : prog3.o sort.o utils.o
cc -o prog3 prog3.o sort.o utils.o
|
我们知道,Makefile中的第一个目标会被作为其默认目标。我们声明了一个“all”的伪目标,其依赖于其它三个目标。由于伪目标的特性是,总是被执行的,所以其依赖的那三个目标就总是不如“all”这个目标新。所以,其它三个目标的规则总是会被决议。也就达到了我们一口气生成多个目标的目的。“.PHONY : all”声明了“all”这个目标为“伪目标”。
显示命令:依赖命令前加@
实例:
1
2
3
4
5
6
7
8
9
10
11
|
test:test.o
gcc test.o -o test
test.o:test.s
gcc -c test.s -o test.o
test.s:test.i
gcc -S test.i -o test.s
test.i:test.c
gcc -E test.c -o test.i
.PHONY:clean
clean:
rm -f test.s test.i test.o test
|
实例Makefile的代码表示的关系是:
test文件依赖于test.o文件,而test.o文件依赖于test.s文件,test.s文件依赖于test.i,文件,test.i文件依赖于test.c文件
本文转自 七十七快 51CTO博客,原文链接:http://blog.51cto.com/10324228/1784985