编写Makefile的第一步,不是一个猛子扎进去试着写一个规则并对之调试,而应该先采用面向依赖关系的思考方法勾勒出makefile要表达怎样的依赖关系,这一点尤为重要。通过不断地练习这种思考方法,才可能达到流畅地编写makefile的能力。
上例的一个依赖关系类图为:
表示simple可执行文件是通过main.c 和 foo.c 编译生成的。通过这个依赖关系图就可以写出一个Makefile来了,但根据这个依赖关系所写出来的Makefile在显示项目中的可维护性很差。
怎样的依赖关系能使我们写出更具维护性的Makefile呢?下图实现了对依赖关系的更精确的表达,其中可以看到目标文件的身影。通过添加源程序文件所对应的目标文件,将有助于写出表达能力更强的Makefile,这也意味着所获得的Makefile更具有可维护性。
通过这个依赖关系图编写Makefile为:
1 all:main.o foo.o 2 gcc -o app main.o foo.o 3 main.o:main.c 4 gcc -o main.o -c main.c 5 foo.o:foo.c 6 gcc -o foo.o -c foo.c 7 clean: 8 rm app main.o foo.o
下图为依赖关系与规则间的映射。
分别编写好两个源文件之后,执行效果如下:
为什么第二次make还是又生成了app这个可执行文件呢?
make是通过文件的时间戳来判定哪些文件需要编译的,所以如果电脑系统时间变更,将可能影响make的执行。由于第二次make的时候,虽然foo和main的目标文件已经生成了,但all目标在编译过程中并不生成,所以在此执行make,又生成了app,更改makefile(红色部分为更改部分)如下:
1 app:main.o foo.o 2 gcc -o app main.o foo.o 3 main.o:main.c 4 gcc -o main.o -c main.c 5 foo.o:foo.c 6 gcc -o foo.o -c foo.c 7 clean: 8 rm app main.o foo.o
这样再有多次执行make并且文件时间戳没有改变时,make会提示你:
make: 'app' is up to date.//app已经是最新的。
我们对foo.c做点改动,看make是否可以发现我们的改动并重新编译,注意make是按照时间戳来判定文件是否有改动的,touch命令可以改变文件的时间戳,这相当于对文件做了一次修改。
touch:将文件的访问及修改时间都更新成目前时间,如果文件不存在,则创建一个字节数为0的空文件。
可以看到touch之后时间戳改变,然后我们make试试。
果然,make察觉到了foo.c的更改,并重新构建了。
现在的makefile虽然能够工作,但不够灵活,下面的文章让makefile更专业。