前面我们讲到了makefile的依赖拆分的知识，现在可以引申出这样一个问题，如果同一个目标的不同命令拆分的写到不同地方会发生什么？下面我们给出程序和执行结果：
可见后面的命令会覆盖前面的命令，我们可以得到以下结论：
我们主观上要避免在多处出现同一目标的不同命令，但是在include一个文件时，往往不自觉的引入这种问题，因此，当使用include关键字包含其他文件时，需要确保被包含文件中的同名目标只有依赖，没有命令，否则同名目标的命令将被覆盖。
下面来具体介绍make的隐式规则，make包含了一个巨大的库，其提供了一些常用的、例行的规则实现，当相应的目标规则未提供时，make尝试使用隐式规则。
看下面一段程序与其make输出：
我们在makefile中并没有提供生成$(OBJS)的规则，但是最终依然成功生成了这些文件，这便是make的隐式规则，其自动查找自身的库，找到合适的规则，并用来生成目标文件。make的隐式规则有以下特性：
下面深入理解一下make的隐式规则：
make的隐式规则很强大，但也带来了很大的副作用：
1、编译行为难以控制，大量使用隐式规则可能产生意想不到的编译行为。
2、编译效率低下，make从隐式规则和自定义规则中选择最终使用的规则。
make还可能会产生隐式规则链，当依赖的目标不存在时，make会极力组合各种隐式规则对目标进行创建，进而产生意料之外的编译行为。例如，需要N.o的目标，make可能会组合成N.y->N.c->N.o规则链。
使用make -p可以查看make提供的所有隐式规则，执行make -p | grep "%.o"，可以得到以下结果：
在工程中，我们应该禁用make的隐式规则，其中包括局部禁用和全局禁用，如下所示：
后缀规则简介：
后缀规则又分为双后缀规则和单后缀规则，它们与现在的模式规则的对应关系分别如下：
后缀规则中不允许有依赖，后缀规则必须有命令，否则无意义，后缀规则将逐步被模式规则取代。
小结：
1、隐式规则可能造成意想不到的行为。
2、在实际工程项目中，尽量不要使用隐式规则。
3、后缀规则是一种陈旧的模式规则，其正在被模式规则取代。
参考如下：
狄泰软件教程及课件
gun make手册
专业嵌入式软件开发