make在执行时，通过目录搜索得到的目标的依赖文件可能会在其它目录（此时依赖文件为文件的完整路径名），但是已经存在的规则命令却不能发生变化。因此，书写命令时我们必须保证当依赖文件在其它目录下被发现时规则的命令能够正确执行。
处理这种问题的方式就是使用“自动化变量”（可参考 9.5.3 自动化变量 一小节），诸如“$^”等。规则命令行中的自动化变量“$^”代表所有的是的通过目录搜索得到的依赖文件的完整路径名（目录+一般文件名）列表。“$@”代表规则的目标。所以对于一个规则我们可以进行如下的描述：
foo.o : foo.c
cc -c $(CFLAGS) $^ -o $@
变量“CFLAGS”是编译.c文件时GCC的命令行选项，可以在Makefile中给它指定明确的值、也可以使用隐含的定义值。
规则的依赖文件列表中可以包含头文件，而在命令行不需要使用这些头文件（这些头文件的作用只有在make程序决定目标是否需要重建时才有意义）。我们可以使用另外一个变量来书代替“$^”，例如：
VPATH = src:../headers
foo.o : foo.c defs.h hack.h
cc -c $(CFLAGS) $< -o $@
自动化变量“$<”代表规则中通过目录搜索得到的依赖文件列表的第一个依赖文件。关于自动化变量我们在后续有专门的讨论。
隐含规则同样会为依赖文件搜索通过变量“VPATH”、或者关键字“vpath”指定的搜索目录。例如：一个目标文件“foo.o”在Makefile中没有重建它的明确规则，make会使用隐含规则来由已经存在的“foo.c”来重建它。当“foo.c”在当前目录下不存在时，make将会进行目录搜索。如果能够在一个可以搜索的目录中找到此文件，同样make会使用隐含规则根据搜索到的文件完整的路径名去重建目标，编译这个.c源文件。
隐含规则中的命令行中就是使用自动化变量来解决目录搜索可能带来的问题；相应的命令中的文件名都是使用目录搜索得到的完整的路径名。（可参考上一小节）
Makefile中程序链接的静态库、共享库同样也可以有目录搜索得到。这一特性需要我们在书规则的依赖是指定一个类似“-lNNAM”的依赖文件名（一个奇怪的依赖文件名！一般依赖文件名应该是一个普通文件的名字。库文件的命名也应该是“libNAME.a”而不是所写的“-lNAME”。这是为什么，熟悉GNU ld的话我想这就不难理解了，“-lNAME”的表示方式和ld的对库的引用方式完全一样，只是我们在书写Makefile的规则时使用了这种书写方式。因此你不应该感到奇怪）。下边我们就来看看这种奇怪的依赖文件到底是什么。
当规则中依赖文件列表中存在一个“-lNAME”形式的文件时。make将根据“NAME”首先搜索当前系统可提供的共享库，如果当前系统不能提供这个共享库，则搜索它的静态库（当然你可以在命令行中指定编译或者连接选项来指定动态连接还是静态连接，这里我们不讨论）。来看一下详细的过程。1. make在执行规则时会在当前目录下搜索一个名字为“libNAME.so”的文件；2. 如果当前工作目录下不存在这样一个文件，则make程序会继续搜索使用“VPATH”或者“vpath”指定的搜索目录。3. 还是不存在，make程序将搜索系统默认目录，顺序是：“/lib”、“/usr/lib”和“PREFIX/lib”（在Linux系统中为“/usr/local/lib”，其他的系统可能不同）。
如果“libNAME.so”通过以上的途径最后还是没有找到的话，那么make程序将会按照以上的搜索顺序查找名字为“libNAME.a”的文件。
假设你的系统中存在“/usr/lib/libcurses.a”（不存在“/usr/lib/libcurses.so”）这个库文件。看一个例子：
foo : foo.c -lcurses
cc $^ -o $@
上例中，如果文件“foo.c”被修改或者“/usr/lib/libcurses.a”被更新，执行规则时将使用命令“cc foo.c /usr/lib/libcurses.a -o foo”来完成目标文件的重建。需要注意的是：如果“/usr/lib/libcurses.a”需要在执行make的时生成，那么就不能这样写，因为“-lNAME”只是告诉了链接器在生成目标时需要链接那个库文件。上例的中的“-lcurses”并没有告诉make程序其依赖的库文件应该如何重建。当搜索的所有目录中不存在库“libcurses”时。Make将提示“没有规则可以创建目标“foo”需要的目标“-lcurses”。如果在执行make时，出现这样的提示信息，你应该明确发生了什么错误，而不要因为错误而不知所措。
当规则的依赖列表中出现了“-lNAME”格式的依赖，默认搜索的文件名为“libNAME.so”和“libNAME.a”，这是由变量“.LIBPATTERNS”来指定的。“.LIBPATTERNS”的值一般是多个包含模式字符（%）的字（一个不包含空格的字符串），多个字之间使用空格分开。在规则中出现“-lNAME”格式的的依赖时，首先使用这里的“NAME”代替变量“.LIBPATTERNS”的第一个字的模式字符（%）而得到第一个库文件名，根据这个文件名在搜索目录下查找，如果能够找到、就是用这个文件，否则使用“NAME”代替第二个字的模式字符，进行同样的查找。默认情况时，“.LIBPATTERNS”的值为：“lib%.so lib%.a”。这也是默认情况下在规则存在“-lNAME”格式的依赖时，链接生成目标时使用“libNAME.so”和“libNAME.a”的原因。
变量“.LIBPATTERNS”就是告诉链接器在执行链接过程中对于出现“-LNAME”的文件如何展开。当然我们也可以将此变量制空，取消链接器对“-lNAME”格式进行展开。
本节我们讨论一个Makefile中的一个重要的特殊目标：伪目标。
伪目标是这样一个目标：它不代表一个真正的文件名，在执行make时可以指定这个目标来执行其所在规则定义的命令，有时我们也可以将一个伪目标称为标签。使用伪目标有两点原因：1. 避免在我们的Makefile中定义的只执行命令的的目标（此目标的目的为了执行执行一些列命令，而不需要创建这个目标）和工作目录下的实际文件出现名字冲突。2. 提高执行make时的效率，特别是对于一个大型的工程来说，编译的效率也许你同样关心。以下就这两个问题我们进行分析讨论：
1. 如果我们需要书写这样一个规则：规则所定义的命令不是去创建目标文件，而是使用make指定具体的目标来执一些特定的命令。像下边那样：
clean:
rm *.o temp
规则中“rm”不是创建文件“clean”的命令，只是删除当前目录下的所有.o文件和temp文件。在工作目录下不存在“clean”这个文件时，我们输入“make clean”后，“rm *.o temp”总会被执行。这是我们的初衷。
但当前工作目录下存在文件“clean”时情况就不一样了，在我们输入“make clean”时。规则没有依赖文件，所以目标被认为是最新的而不去执行规则作定义的命令，命令“rm”将不会被执行。这并不是我们的初衷。为了避免这个问题，我们可以将目标“clean”明确的声明为伪目标。将一个目标声明为伪目标需要将它作为特殊目标.PHONY”的依赖。如下：
.PHONY : clean
这样目标“clean”就是一个伪目标，无论当前目录下是否存在“clean”这个文件。我们输入“make clean”之后。“rm”命令都会被执行。而且，当一个目标被声明为伪目标后，make在执行此规则时不会试图去查找隐含规则来创建这个目标。这样也提高了make的执行效率，同时我们也不用担心由于目标和文件名重名而使我们的期望失败。在书写伪目标规则时，首先需要声明目标是一个伪目标，之后才是伪目标的规则定义。目标“clean”书写格式应该如下：
.PHONY: clean
clean:
rm *.o temp
2. 伪目标的另外一使用场合在make的并行和递归执行过程中。此情况下一般存在一个变量，其定义为所有需要make的子目录。对多个目录进行make的实现方式可以在一个规则中可以使用shell的循环来完成。如下：
SUBDIRS = foo bar baz
subdirs:
for dir in $(SUBDIRS); do \
$(MAKE) -C $$dir; \
done
但这种实现方法存在以下几个问题。1. 当子目录执行make出现错误时，make不会退出。就是说，在对某一个目录执行make失败以后，会继续对其他的目录进行make。在最终执行失败的情况下，我们很难根据错误的提示定位出具体是是那个目录下的Makefile出现错误。这给问题定位造成了很大的困难。为了避免这样的问题，我们可以在命令行部分加入错误的监测，在命令执行错误后make退出。不幸的是，如果在执行make时使用了“-k”选项，此方式将失效。2. 另外一个问题就是使用这种shell的循环方式时，没有用到make对目录的并行处理功能，因为规则的命令是一条完整的shell命令，不能被并行的执行。
我们可以通过伪目标方式来克服以上实现方式所存在的两个问题。
SUBDIRS = foo bar baz
.PHONY: subdirs $(SUBDIRS)
subdirs: $(SUBDIRS)
$(SUBDIRS):
$(MAKE) -C $@
foo: baz
上边的实现中使用了一个没有命令行的规则“foo: baz”，用来限制子目录的make顺序。此规则的含义时在处理“foo”目录之前，需要等待“baz”目录处理完成。在书写一个并行执行make的Makefile时，目录的处理顺序是需要特别注意的。
一般情况下，一个伪目标不作为一个另外一个目标文件的依赖。这是因为当一个目标文件的依赖包含伪目标时，每一次在执行这个规则时伪目标所定义的命令都会被执行（因为它是规则的依赖，重建规则目标文件时需要首先重建它的依赖）。当伪目标没有作为任何目标（此目标是一个可被创建或者已存在的文件）的依赖时，我们只能通过make的命令行选项明确指定这个伪目标，来执行它所定义的命令。例如我们的“make clean”。
Makefile中，伪目标可以有自己的依赖。在一个目录下如果需要创建多个可执行程序，我们可以将所有程序的重建规则在一个Makefile中描述。因为Makefile中第一个目标是“终极目标”，约定的做法是使用一个称为“all”的伪目标来作为终极目标，它的依赖文件就是那些需要创建的程序。下边就是一个例子：
#sample Makefile
all : prog1 prog2 prog3
.PHONY : all
prog1 : prog1.o utils.o
cc -o prog1 prog1.o utils.o
prog2 : prog2.o
cc -o prog2 prog2.o
prog3 : prog3.o sort.o utils.o
cc -o prog3 prog3.o sort.o utils.o
执行make时，目标“all”被作为终极目标。为了完成对它的更新，make会创建（不存在）或者重建（已存在）目标“all”的所有依赖文件（prog1、prog2和prog3）。当需要单独更新某一个程序时，我们可以通过make的命令行选项来明确指定需要重建的程序。（例如： “make prog1”）。
当一个伪目标作为另外一个伪目标依赖时，make将其作为另外一个伪目标的子例程来处理（可以这样理解：其作为另外一个伪目标的必须执行的部分，就行C语言中的函数调用一样）。下边的例子就是这种用法：
.PHONY: cleanall cleanobj cleandiff
cleanall : cleanobj cleandiff
rm program
cleanobj :
rm *.o
cleandiff :
rm *.diff
“cleanobj”和“cleandiff”这两个伪目标有点像“子程序”的意思（执行目标“clearall时会触发它们所定义的命令被执行”）。我们可以输入“make cleanall”和“make cleanobj”和“make cleandiff”命令来达到清除不同种类文件的目的。例子首先通过特殊目标“.PHONY”声明了多个伪目标，它们之间使用空各分割，之后才是各个伪目标的规则定义。
说明：
通常在清除文件的伪目标所定义的命令中“rm”使用选项“–f”（--force）来防止在缺少删除文件时出错并退出，使“make clean”过程失败。也可以在“rm”之前加上“-”来防止“rm”错误退出，这种方式时make会提示错误信息但不会退出。为了不看到这些讨厌的信息，需要使用上述的第一种方式。
另外make存在一个内嵌隐含变量“RM”，它被定义为：“RM = rm –f”。因此在书写“clean”规则的命令行时可以使用变量“$(RM)”来代替“rm”，这样可以免出现一些不必要的麻烦！这是我们推荐的用法。
