2024年最新《Makefile 进阶之路二》 这里有你对Makefile所有的畅想(2)，2024年最新这份1307页Web前端面试全套真题解析

总结

• 对于框架原理只能说个大概，真的深入某一部分具体的代码和实现方式就只能写出一个框架，许多细节注意不到。

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

• 算法方面还是很薄弱，好在面试官都很和蔼可亲，擅长发现人的美哈哈哈…（最好多刷一刷，不然影响你的工资和成功率???）

• 在投递简历之前，最好通过各种渠道找到公司内部的人，先提前了解业务，也可以帮助后期优秀 offer 的决策。

• 要勇于说不，对于某些 offer 待遇不满意、业务不喜欢，应该相信自己，不要因为当下没有更好的 offer 而投降，一份工作短则一年长则 N 年，为了幸福生活要慎重选择！！！

第一次跳槽十分忐忑不安，和没毕业的时候开始找工作是一样的感受，真的要相信自己，有条不紊的进行。如果有我能帮忙的地方欢迎随时找我，比如简历修改、内推、最起码，可以把烦心事说一说，人嘛都会有苦恼的～

祝大家都有美好的未来，拿下满意的 offer。

在所有需要依赖列表的地方使用$(objs)代替。以上代码完全等价与原始的代码。而且，当我们需要增加或者删除依赖的时候，仅仅需要修改objs变量就可以了。以此为启发，我们在clean处的代码也可以写为：

clean:

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可以使用两个方法：

最后

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
就答题情况而言，第一问100%都可以回答正确，第二问大概只有50%正确率，第三问能回答正确的就不多了，第四问再正确就非常非常少了。其实此题并没有太多刁钻匪夷所思的用法，都是一些可能会遇到的场景，而大多数人但凡有1年到2年的工作经验都应该完全正确才对。
只能说有一些人太急躁太轻视了，希望大家通过此文了解js一些特性。

并祝愿大家在新的一年找工作面试中胆大心细，发挥出最好的水平，找到一份理想的工作。