rm edit $(objs)
2.2 自动推导命令规则
我们观察修改过后的Makefile文件:
`1 objs = main.o kbd.o command.o display.o \ 2 insert.o search.o files.o utils.o 3 edit : $(objs) 4 cc -o edit $(objs) 5 main.o : main.c defs.h 6 cc -c main.c 7 kbd.o : kbd.c defs.h command.h 8 cc -c kbd.c 9 command.o : command.c defs.h command.h 10 cc -c command.c 11 display.o : display.c defs.h buffer.h 12 cc -c display.c 13 insert.o : insert.c defs.h buffer.h 14 cc -c insert.c 15 search.o : search.c defs.h buffer.h 16 cc -c search.c 17 files.o : files.c defs.h buffer.h command.h 18 cc -c files.c 19 utils.o : utils.c defs.h 20 cc -c utils.c 21 clean : 22 rm edit $(objs)`
可以明显的发现,在“.o”文件的生成时,"cc -c *.c"重复出现,其实我们可以知道,当我们写过TARGET和PREREQUISITES(依赖)之后,下方的命令应该是怎么样的。所以,编译.c源文件规则的命令可以不用明确给出。这是因
为make本身存在一个默认的规则,能够自动完成对.c文件的编译并生成对应的.o文件。它执行命令“cc -c”来编译.c源文件。在Makefile中我们只需要给出需要重建的目标文件名(一个.o文件),make会自动为这个.o文件寻找合适的依赖文件(对应的.c文件。对应是指:文件名除后缀外,其余都相同的两个文件),而且使用正确的命令来重建这个目标文件。
对一个目标文件是“N.o”,倚赖文件是“N.c”的规则,完全可以省略其规则的命令行,而由make自身决定使用默认命令。此默认规则称为make的隐含规则。
因此上边的例子就可以以更加简单的方式书写,我们同样使用变量“objs”。Makefile 内容如下:
`1 # sample Makefile 2 objs = main.o kbd.o command.o display.o \ 3 insert.o search.o files.o utils.o 4 edit : $(objs) 5 cc -o edit $(objs) 6 main.o : defs.h 7 kbd.o : defs.h command.h 8 command.o : defs.h command.h 9 display.o : defs.h buffer.h 10 insert.o : defs.h buffer.h 11 search.o : defs.h buffer.h 12 files.o : defs.h buffer.h command.h 13 utils.o : defs.h 14 .PHONY : clean # 为什么这样写,本篇下面有解释 15 clean : 16 rm edit $(objs)`
2.3 另一种风格(不推荐的方式)
如果在这个 Makefile 中,我们是根据依赖而不是目标对规则进行分组。形成另外一种风格的 Makefile。我们观察可以发现,所有的“.o”文件都需要依赖"defs.h",而一部分还依赖“command.h”,另一部分依赖“buffer.h”。我们可以整理上面的Makefile成为如下风格:
`1 #sample Makefile 2 objects = main.o kbd.o command.o display.o \ 3 insert.o search.o files.o utils.o 4 edit : $(objects) 5 cc -o edit $(objects) 6 $(objects) : defs.h #所有“.o”文件都依赖“defs.h” 7 kbd.o command.o files.o : command.h #依赖“command.h”的一部分 8 display.o insert.o search.o files.o : buffer.h #依赖“buffer.h”的一部分`
这种风格的 Makefile 并不值得我们借鉴。问题在于:同时把多个目标文件的依赖放在同一个规则中进行描述(一个规则中含有多个目标文件),这样导致规则定义不明了,比较混乱。建议大家不要在 Makefile 中采用这种方式了书写。否则后期维护将会是一件非常痛苦的事情。书写规则建议的方式是:单目标,多依赖。就是说尽量要做到一个规则中只存在一个目标文件,可有多个依赖文件。尽量避免使用多目标,单依赖的方式。
2.4 清除工作(clean)
最初,我们的清除工作如下:
clean :
rm edit $(objects)
在实际应用时,我们把这个规则写成如下稍微复杂一些的样子。以防止出现始料未及的情况。
.PHONY : clean
clean :
-rm edit $(objects)
这两个实现有两点不同: 1. 通过“.PHONY”特殊目标将“clean”目标声明为伪目标。避免当磁盘上存在一个名为“clean”文件时,目标“clean”所在规则的命令无法执行。2. 在命令行之前使用“-”,意思是忽略命令“rm”的执行错误。
这样的一个目标在 Makefile 中,不能将其作为终极目标(Makefile 的第一个目标,终极目标没有后缀,在极端巧合的情况下会是“clean”,导致编译错误)。因为我们的初衷并不是当你在命令行上输入 make 以后执行删除动作。而是要创建或者更新程序。在我们上边的例子中。就是在输入 make 以后要需要对目标“edit”进行创建或者重建。
----------------------------以下非正文
总结:
简化Makefile可以使用两个方法:
1.使用变量定义,将依赖列表赋值给一个变量,在需要使用列表的地方,用变量代替
2.使用隐含规则,“.o”目标行的依赖列表中的“.c”文件和对应命令行
最后,可以使用特殊的目标“.PHONY”将“clean”定义为一个伪目标,从而避免极端情况下,终极目标正好是“clean”的情况。
到此为止,网络上一般的介绍都结束了,但是了解到这里仅仅算到了门口而已,如果真的想要使用Makefile呼风唤雨,还需要更加神秘的功能。
尊重原创,引用请注明出处
[
最后
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长,自己不成体系的自学效果低效漫长且无助。
因此收集整理了一份《2024年Web前端开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点!不论你是刚入门Android开发的新手,还是希望在技术上不断提升的资深开发者,这些资料都将为你打开新的学习之门!
如果你觉得这些内容对你有帮助,需要这份全套学习资料的朋友可以戳我获取!!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,需要这份全套学习资料的朋友可以戳我获取!!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!