在Makefile中，静态模式规则和被定义为隐含规则的模式规则都是我们经常使用的两种方式。两者相同的地方都是用目标模式和依赖模式来构建目标的规则中的文件依赖关系，两者不同的地方是make在执行时使用它们的时机。
隐含规则可被用在任何和它相匹配的目标上，在Makefile中没有为这个目标指定具体的规则、存在规则但规则没有命令行或者这个目标的依赖文件可被搜寻到。当存在多个隐含规则和目标模式相匹配时，只执行其中的一个规则。具体执行哪一个规则取决于定义规则的顺序。
相反的，静态模式规则只能用在规则中明确指出的那些文件的重建过程中。不能用在除此之外的任何文件的重建过程中，并且它对指定的每一个目标来说是唯一的。如果一个目标存在于两个规则，并且每一个规则中都定以了命令，make执行时就会提示错误。
静态模式规则相比隐含模式规则由以下两个优点：
² 不能根据文件名通过词法分析进行分类的文件，我们可以明确列出这些文件，并使用静态模式规则来重建其隐含规则。
² 对于无法确定工作目录内容，而且不能确定是否此目录下的无关文件会使用错误的隐含规则而导致make失败的情况。当存在多个适合此文件的隐含规则时，使用哪一个隐含规则取决于其规则的定义顺序。这种情况下我们使用静态模式规则就可以避免这些不确定因素，因为静态模式中，指定的目标文件有特定的规则来描述其依赖关系和重建命令。
双冒号规则就是使用“::”代替普通规则的“:”得到的规则。当同一个文件作为多个规则的目标时，双冒号规则的处理和普通规则的处理过程完全不同（双冒号规则允许在多个规则中为同一个目标指定不同的重建目标的命令）。
首先需要明确的是：Makefile中，一个目标可以出现在多个规则中。但是这些规则必须是同一种规则，要么都是普通规则，要么都是双冒号规则。而不允许一个目标同时出现在两种不同的规则中。双冒号规则和普通规则的处理的不同点表现在以下几个方面：
1. 双冒号规则中，当依赖文件比目标更新时。规则将会被执行。对于一个没有依赖而只有命令行的双冒号规则，当引用此目标时，规则的命令将会被无条件执行。而普通规则，当规则的目标文件存在时，此规则的命令永远不会被执行（目标文件永远是最新的）。
2. 当同一个文件作为多个双冒号规则的目标时。这些不同的规则会被独立的处理，而不是像普通规则那样合并所有的依赖到一个目标文件。这就意味着对这些规则的处理就像多个不同的普通规则一样。就是说多个双冒号规则中的每一个的依赖文件被改变之后，make只执行此规则定义的命令，而其它的以这个文件作为目标的双冒号规则将不会被执行。
我们来看一个例子，在我们的Makefile中包含以下两个规则：
Newprog :: foo.c
$(CC) $(CFLAGS) $< -o $@
Newprog :: bar.c
$(CC) $(CFLAGS) $< -o $@
如果“foo.c”文件被修改，执行make以后将根据“foo.c”文件重建目标“Newprog”。而如果“bar.c”被修改那么“Newprog”将根据“bar.c”被重建。回想一下，如果以上两个规则为普通规时出现的情况是什么？（make将会出错并提示错误信息）
当同一个目标出现在多个双冒号规则中时，规则的执行顺序和普通规则的执行顺序一样，按照其在Makefile中的书写顺序执行。
GNU make的双冒号规则给我们提供一种根据依赖的更新情况而执行不同的命令来重建同一目标的机制。一般这种需要的情况很少，所以双冒号规则的使用比较罕见。一般双冒号规则都需要定义命令，如果一个双冒号规则没有定义命令，在执行规则时将为其目标自动查找隐含规则。
Makefile中，可能需要书写一些规则来描述一个.o目标文件和头文件的依赖关系。例如，如果在main.c中使用“#include defs.h”，那么我们可能需要如下那样的一个规则来描述当头文件“defs.h”被修改以后执行make，目标“main.o”应该被重建。
main.o: defs.h
这样，在一个比较大型的工程中。就需要在Makefile中书写很多条类似于这样的规则。并且，当在源文件中加入或删除头文件后，也需要小心地去修改Makefile。这是一件很费力、也很费时并且容易出错误的工作。为了避免这个令人讨厌的问题，现代的c编译器提供了通过查找源文件中的“#include”来自动产生这种依赖的功能。“GCC”支持一个“-M”的选项来实现此功能。“GCC”将自动找寻源文件中包含的头文件，并生成一个依赖关系。例如，如果“main.c”只包含了头文件“defs.h”，那么在Linxu下执行下面的命令：
gcc -M main.c
其输出是：
main.o : main.c defs.h
既然编译器已经提供了自动产生依赖关系的功能，那么我们就不需要去动手写这些规则的依赖关系了。但是需要明确的是：在“main.c”中包含了其他的标准库的头文件，其输出的依赖关系中也包含了标准库的头文件。当不需要依赖关系中不考虑标准库头文件时，需要使用“-MM”参数。
需要注意的是，在使用“GCC”自动产生依赖关系时，所产生的规则中明确的指明了目标是“main.o”文件。一次在通过.c文件直接产生可执行文件时，作为过程文件的“main.o”的中间过程文件在使用完之后将不会被删除。
在旧版本的make中，使用编译器此项功能通常的做法是：在Makefile中书写一个伪目标“depend”的规则来定义自动产生依赖关系文件的命令。输入“make depend”将生成一个称为“depend”的文件，其中包含了所有源文件的依赖规则描述。Makefile使用“include”指示符包含这个文件。
在新版本的make中，推荐的方式是为每一个源文件产生一个描述其依赖关系的makefile文件。对于一个源文件“NAME.c”，对应的这个makefile文件为“NAME.d”。“NAME.d”中描述了文件“NAME.o”所要依赖的所有头文件。采用这种方式，只有源文件在修改之后才会重新使用命令生成新的依赖关系描述文件“NAME.o”。
我们可以使用如下的模式规则来自动生成每一个.c文件对应的.d文件：
%.d: %.c
$(CC) -M $(CPPFLAGS) $< > $@.$$$$; \
sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \
rm -f
此规则的含义是：所有的.d文件依赖于同名的.c文件。
第一行；使用c编译器自自动生成依赖文件（$<）的头文件的依赖关系，并输出成为一个临时文件，“$$$$”表示当前进程号。如果$(CC)为GNU的C编译工具，产生的依赖关系的规则中，依赖头文件包括了所有的使用的系统头文件和用户定义的头文件。如果需要生成的依赖描述文件不包含系统头文件，可使用“-MM”代替“-M”。
第二行；使用sed处理第二行已产生的那个临时文件并生成此规则的目标文件。这里sed完成了如下的转换过程。例如对已一个.c源文件。将编译器产生的依赖关系：
main.o : main.c defs.h
转成：
main.o main.d : main.c defs.h
这样就将.d加入到了规则的目标中，其和对应的.o文件文件一样依赖于对应的.c源文件和源文件所包含的头文件。当.c源文件或者头文件被改变之后规则将会被执行，相应的.d文件同样会被更新。
第三行；删除临时文件。
使用上例的规则就可以建立一个描述目标文件依赖关系的.d文件。我们可以在Makefile中使用include指示符将描述将这个文件包含进来。在执行make时，Makefile所包含的所有.d文件就会被自动创建或者更新。Makefile中对当前目录下.d文件处理可以参考如下：
sources = foo.c bar.c
sinclude $(sources:.c=.d)
例子中，变量“sources”定义了当前目录下的需要编译的源文件。变量引用变换“$(sources : .c=.d)”的功能是根据需要.c文件自动产生对应的.d文件，并在当前Makefile文件中包含这些.d文件。.d文件和其它的makefile文件一样，make在执行时读取并试图重建他们。其实这些.d文件也是一些可被make解析的makefile文件。
需要注意的是include指示符的书写顺序，因为在这些.d文件中已经存在规则。当一个Makefile使用指示符include这些.d文件时，应该注意它应该出现在终极目标之后，以免.d文件中的规则被是Makefile的终极规则。关于这个前面我们已经有了比较详细的讨论。
