今天不打算写长篇，简单点把这个系列完结。只谈一下前面欠下的一些问题。

对于大工程，在 VS 里，我通常是以虚拟文件夹和子工程的方式来管理的。不知道其他同学跟我是不是一个习惯。从 VC 6.0 以后，我几乎就没碰过 VS 了。不太清楚现在微软的 IDE 目前的发展趋势。我想可能有更好的组织方式吧。

但如果离开 VS ，我们用 GNU Make ，或是别的类似的工具（例如我用过的 Boost Jam ，或是前面有朋友推荐的 CMake 等）按惯例，通常按 OS 的文件目录结构来管理大的项目。即，一个子项目放在一个子目录中。对于一个大模块，即使它可能是一个子项目中不可分割的一部分，通常也以静态库的形式被分离出来。哪怕这个静态库只被一个地方引用。

把源代码拆分成适当的规模，并分类组织在不同的文件目录下，是一个好的习惯。

那么你在编写 Makefile 的时候，就可以为每个源代码的子目录编写一个 Makefile 。那么怎么让若干处于不同子目录下，甚至多层深度下的 Makefile 协同工作？Make 的惯例是利用 Shell 递归调用自己。

比如你的 src 目录下有两个子项目，foo1 和 foo2 。你在 src 根下的 Makefile 一般会这样写：

all : 
    cd foo1 && $(MAKE) all
    cd foo2 && $(MAKE) all
clean:
    cd foo1 && $(MAKE) clean
    cd foo2 && $(MAKE) clean

$(MAKE) 是一个预定义的变量，里面保存的就是调用 Make 自己的 Shell 指令。

看起来比较繁琐，所以我的习惯是，把 foo1 foo2 这些子目录提取出来。

DIRS= foo1 foo2

all : $(DIRS:=.all)
clean : $(DIRS:=.clean)

%.all :
    cd $* && $(MAKE) all
%.clean:
    cd $* && $(MAKE) clean

这个版本依然有许多重新的东西，也是可以去掉的，但那势必引出更多的“高级”用法，暂时就不展开了。其中用到的知识前面我们都介绍过了。除了 $* ，这个是表示目标中除掉 .ext 后缀的部分字符串。

按前几篇的流程走下来，你会发现，在 build 工程的时候，往往在源代码目录留下许多中间文件。我们在前面的例子中都写上了 clean 这个目标，用来清除中间文件。但事实上，在 GNU Make 的手册里，并不建议我们如此的污染源代码目录。一般来说，我们会定义一个中间文件的输出目录。这需要少许的技巧，但是不难办到，这里就不举例了。

因为早年使用 VS 的缘故，我喜欢同时维护至少两个版本的中间文件。一个 Debug 版，一个 Release 版，分放在不同的中间文件目录中，重新 build debug 版，不会影响到 Release 版的重构建。对于这个需求 Boost Jam 做的相当不错。甚至弄的更华丽，你可以轻易的拥有 "关闭 RTTI 设置的 Release 版“ 、”打开 C++ 异常的 Debug 版“ 等等。不过 boost jam 也为这华丽的功能付出了一点点小小的代价……

我们说回 Make ，最简单的方法是，再编译不同的版本的时候，选用不同的变量取值，例如：不同的优化开关、不同的输出目录。GNU Make 支持类似 C 语言中 #if 的条件语句，但是不能完全解决这个问题。还需要动用的一个特性是，GNU Make 支持定义目标相关的变量：

release : CFLAGS=/O2

debug : CFLAGS=/Zi

即这样的写法，它使得一个变量的取值在编译某个特定目标的时候才有效。具体怎么做达到你心目中的需求，就留给同学们自己思考了。

记住，是工具就需要学习。多用才可以提高对工具的掌握程度。对于编写 Makefile 文件，不要抱着修改配置文件那样的心态，而要把它当成一门语言，一门可以提高你的工作效率的语言。通过计算机语言教会计算机做本该你亲手来做的操作，这是程序员之道。

为了利用计算机帮助我们达到一个目的，原本有许多方法。有普通人的方式，有程序员的方式。程序员的方式是教会计算机代我们去做；普通的人方式是利用计算机协助我们去做。在 IDE 里，有时我们也想办法用独特的方式去教计算机做一些事情。IMHO, C++ 以及其千奇百怪的特性挖掘，建立出丰富的模板库很大程度就是来源于此。比如 boost 里有个叫 Boost::Spirit 的库，可以让 C++ 程序员书写近似的 BNF 的式子，生成一个解析器去分析它。但是为什么不考虑直接用 yacc 呢？它天然的就是为了处理 bnf 而存在的。因为 IDE 并不是一个很好的粘合剂，用来粘合这些工具。所以，我们把粘合层下移到了 C++ 编译器的层面。不幸的是，一旦我们给一个单一工具附加了太多使命后，无论是 IDE 还是 C++ 编译器，它们都会迅速的臃肿，直到不能承担；或者，我们干脆改变问题，让问题去适应解决手段，而不是接受手段去适应问题。

Make 是一个好的起点，它展示了一个功能单一简洁的工具，能且只能完成一个工具粘合剂的使命。并且完全以计算机的方式去工作。工具和工具之间以命令行，返回码，标准输入输出管道的方式藕荷。和人交互的界面是简单可读的文本。层次分明，顾而可堪大任。

多说无益，既然已经没有多少兴致向下写。就把剩下的时间集中在几个前面提到过的问题的解决上。剩下的一切就靠同学们自己研究摸索了。离开 IDE ，你应该得到了一片更广阔的天空，一切适合计算机协作的工具（有命令行接口）都能拿来使用。你不用再局限于别人是否给你提供了源代码，是否有良好的 DLL 插件接口，而只用关心前人做的工具是否适合你现在的需要。你用自己的头脑去发现捷径，而不是 google 一个 step by step 的教程。

问题一，如何让编译流程自动得到 .h 头文件的依赖关系？

C 语言的源文件依赖头文件是一个语言层面的东西，跟 Make 工具无关。有些构建工具，比如我曾经使用过的 boost jam 可以编写代码扫描器来完成这些，但 GNU Make 是没有的。没有并不是坏事，一个优秀的工具的原则应该是：努力做好一件事，并只做这一件。其实，分析源代码找到依赖之头文件，并不是一件容易的事情，至少你需要实现 C 语言的宏的解析工作。这应该是 C/C++ 编译器的一部分。

可惜我在 VC 中没找到编译选项可以只完成头文件依赖关系的处理流程。所以，如果你想在 Windows 下使用机器自动生成依赖关系，还得装一个 gcc 。Mingw 的 gcc 是一个不错的选择。你完全可以用 gcc 去分析头文件的依赖关系，再用 vc 来编译代码，虽然有点奇怪，但有何不可呢？一切工具皆可为我所用。

gcc 在命令行加上参数 -MM ，即可生成 GNU Make 格式的依赖关系文本（包括直接和间接的关系）。这个文本输出在标准输出上。但是，其输入格式里，目标文件的后缀是 .o 而不是 VC 默认的 .obj 。不过没有关系，VC 编译 .c 生成 .o 而不是 .obj 就好了。

下面来看我们前面几篇提到的那个小项目，foo.c bar.c foo.h 最后编译生成 foobar.exe 。我写一个完整的改进版在下面：

SRCS=foo.c bar.c
OBJS=$(SRCS:.c=.o)
MAKEDEPEND=gcc -MM
CFLAGS=/Zi 

all : foobar.exe

.depend:
    $(MAKEDEPEND) $(SRCS) > $@

depend:
    -del .depend
    $(MAKE) .depend

clean :
    -del foobar.exe $(OBJS)

foobar.exe : $(OBJS)

%.exe :
    link /out:$@ $^

$(OBJS) : %.o : %.c
    cl /c /Fo$@ $(CFLAGS) $<

include .depend

这里出现了许多前面没有提到过的陌生用法。下面一一讲解：

SRCS=foo.c bar.c
OBJS=$(SRCS:.c=.o)

仅凭猜测，我们就能知道，OBJS 会被定义成 foo.o bar.o 。GNU Make 有着强大的字符串处理功能，非常适合做这类事情。像这种后缀匹配替换，用这个简单的语法就可以表达了。如果在 SRCS 里定义了多种不同后缀的字符串，比如有 .c .cpp .asm 等等，我们可以先筛选出 .c 的部分，即 CSRCS = $(filter %.c,$(SRCS)) 。这里不再详述。

需要稍加说明的是这里的一个赋值：OBJS=$(SRCS:.c=.o) 。OBJS 的值依赖了另一个变量 SRCS 。那么，OBJS 的求值过程是什么是否发生的呢？这个对于敏感的程序员应该是头脑中立刻显现的问题。

答案是，直到 OBJS 被真正用到，取值的时候，$(SRCS:.c=.o) 的求值过程才被触发。也就是说，你可以在下面修改 SRCS 的值（通过 = 或 += 等）而 OBJS 的值总是正确的。

btw, 如果你希望求值过程立刻进行，可以用 := 而不是 = 。具体请翻阅 GNU Make 的文档。

在 Makefile 的最后，include .depend 包含了一个暂时还不存在的 .depend 文件。当 Make 工作的时候，发现一个文件不存在，都会试图构建它，include 指令中出现的文件也不例外。所以，第一次运行，会触发 .depend 文件的构建。

.depend:
    $(MAKEDEPEND) $(SRCS) > $@

通过调用 gcc -MM ，gcc 会输出类似 foo.o : foo.c foo.h 这样的文本行，借助命令行管道操作，我们把输出定向到了 $@ ，即文件 .depend 中。

而第 2 次运行 Make ，由于 .depend 文件已经存在，依赖关系则不再构建。

如果我们修改了 .c 文件中引用的 .h 文件怎么办？简单的方法就是删除 .depend ，重新 Make 。当然，这里我们提供了一个叫做 depend 的伪目标来帮我们做这件事情。

depend:
    -del .depend
    $(MAKE) .depend

这里出现了一个 $(MAKE) 没有定义的变量。这个变量是由 Make 自己定义的，它的值即为自己的位置，方便 Make 递归调用自己。在以后的篇章里，我们会继续发现 Make 自身递归调用的威力。

还有问题吗？

自然是有的。

.depend 文件并不能自动随着项目源码的修改而变更。这显然不够自动化。只不过我们在改进这一点时，需要先问一下自己，你的项目真的需要这个吗？很多项目，并不常变更依赖关系。而作为开发人员自己，在不段的修改代码时，心里非常清楚什么时候应该重新 gmake depend 。而对于第一编译项目，且很有可能不再修改源代码重新编译的人来说，生成一次 .depend 文件足够了。

我们可以简单的让 .depend 文件每次重新生成，这或许比仔细检查每个文件的变更情况然后重新生成更为廉价。（为什么？怎么做？这两个问题同学们自己思考：）

简单的在 .depend : 后加一个依赖关系，比如 .depend : $(SRCS) 行不行？在这个例子里没有问题，但是如果更复杂的情况下，比如 .h 文件中又包含了新的 .h ，可能就不能正确的重构 .depend 文件了。

另一方面，.depend 包含了所有 .c 文件和 .h 文件的依赖关系，因为一个文件的变更而重新扫描所有源文件值得吗？

这个问题不好回答。如果项目太大太大，或许有性能问题。不过，为什么你要把这么大的项目所有源文件放在一个子项目中？要知道，使用 Make 构建子项目，比如说一个静态库，是非常廉价的。（这个问题以后再来探讨）

无论如何，没有不能解决的问题。我们自然可以去生成独立的依赖关系描述文件，然后把依赖关系的描述文件和构建过程本身建立依赖关系。这个做起来比较复杂，但是也很有趣。（提示：gcc 的新版本命令行支持 -MMD ，可以把 .o 换为 .d ，这个功能目的何在？）不过，云风提醒大家，切勿钻牛角尖。一切工具只是帮助我们更便捷的达到目标。我们要认清目标，再选择好工具和恰当的用法。

今天就到这里，下一次我们继续讨论另外几个常见问题：如何管理和组织源文件树木更多的项目，怎么组织负责的源代码目录树。以及怎样像 VS 做的那样，为 Release 版和 Debug 版的目标文件分目录存放，并保存源代码目录的清洁。

昨天我们最终的 Makefile 版本是这样的：

all : foobar.exe

clean :
    -del foobar.exe foo.obj bar.obj

foobar.exe : foo.obj bar.obj
    link /out:$@ $^

foo.obj : foo.c
    cl /c $<

bar.obj : bar.c
    cl /c $<

我们能看出，其中有许多重复的信息，让我们一点点的去掉它们。

首先，将 .c 文件编译成 .obj 文件的方法是一样的。在 GNU Make 里，我们可以为其写一个通用的规则：

%.obj : %.c
    cl /c $<

注意，这并非传统的 makefile 的写法（传统规则定义方法就不介绍了），而是 GNU Make 扩展，以后我们就不再为 GNU Make 做特别说明了。

它的含义是，所有以 .obj 结尾的目标，都依赖于相同模式，但以 .c 结尾的文件。并且这类文件用统一的构建方法：cl /c $< 。$< 我们在前面已经反复提到过，它表示以上的第一个依赖文件。这个符号看起来有些怪异比较难记忆。如果你用 BSD Make ，那么就写作 ${.IMPSRC} 可能会舒服点。其实习惯了后都不错。

% 可以看成一通配符，%.obj 是一个后缀匹配，用 . 做文件后缀名的区分仅仅是一个习惯。如果你愿意，自然也可以写 %obj 去匹配所有obj 结尾的文件。

Makefile 既可简化为：

all : foobar.exe

clean :
    -del foobar.exe foo.obj bar.obj

foobar.exe : foo.obj bar.obj
    link /out:$@ $^

%.obj : %.c
    cl /c $<

因为这里只生成了一个 exe 文件，要是有多个 exe 文件生成，那个 link 也应该可以提取出来。可以写成：

all : foobar.exe

clean :
    -del foobar.exe foo.obj bar.obj

foobar.exe : foo.obj bar.obj

%.exe :
    link /out:$@ $^

%.obj : %.c
    cl /c 

这个版本里，foobar.exe 和 %.exe 被分开定义了，根据我们前面的介绍，知道这样是合法的。一个目标可以有多次的依赖关系定义，Make 只是顺着往它的依赖关系表里添加而已。

接下来，我们发现 foo.obj bar.obj 在两个地方出现。程序员很自然的会想到，让我们用一个变量记录下它们。对 Make 支持变量。定义变量很简单，使用 = 赋值即可。还可以用 += 追加。更多的用法可以去查参考手册。而使用一个标量，则用 $(变量名) 这样的形式。因为 $ 对于 Makefile 文件有特殊含义，所以，一旦你需要在命令行部分（Tab 开头的那些行）写上 $ 就用两个代替，写作 $$ 。

COBJS=foo.obj bar.obj

all : foobar.exe

clean :
    -del foobar.exe $(COBJS)

foobar.exe : $(COBJS)

%.exe :
    link /out:$@ $^

%.obj : %.c
    cl /c 

现在看起来是这样了。我们的定义了一个变量 COBJS ，保存了跟 foobar.exe 有关的所有 obj 文件名。然后在下面用这个变量替换掉。这是个很基本的用法，看起来没有什么意义，但是现在我们考虑一个问题：如果我们使用 C 和 C++ 混合编程，或者再使用了汇编等别的语言。这样，项目里的 .obj 文件就不全是由 .c 文件生成的了。这样，%.obj : %.c 这条规则有有了问题。

因为如果你连续定义

%.obj : %.c
    cl /c 

%.obj : %.cpp
    cl /c 

这里 %.obj 文件有了两条生成方法（虽然它们相同），这是不允许的。注意：简单的定义 %.obj : %.c 和 %.obj : %.cpp 则是合法的，它只是个 %.obj 增加了依赖关系而已。但是导致错误的解决问题：我们生成 .obj 文件并不需要同时拥有同名的 .c 和 .cpp 。

怎么办？

让我们进一步改进一下：

$(COBJS) : %.obj : %.c
    cl /c 

写成这样即可。这一句的变量展开是什么呢？

foo.obj bar.obj : %.obj : %.c
    cl /c 

根据前面我们已经具备的知识，我们知道这个等价于：

foo.obj : %.obj : %.c
    cl /c 

bar.obj : %.obj : %.c
    cl /c 

这是一个严格的模式匹配的过程：foo.obj : %.obj : %.c 表示了，用 %.obj 试着匹配 foo.obj ，如果成功 % 就等于 foo ，如果不成功，Make 会警告你。然后，给 foo.obj 添加了依赖文件 foo.c （用 foo 替换了 %.c 里的 % ）

注：对于现在版本的 GNU Make ，（含 % ）模式规则定义可以不考虑这种问题。如果一个目标有两条规则可以匹配上，会通过检查所依赖的目标是否存在来决定适用哪条规则。但是，以上的方案在间接目标构建中依然有用。

现在回头来看看昨天的一篇最后那个问题：为什么 foo.c 中包含了 foo.h 文件，但是不能在 Makefile 中写 foo.c : foo.h ？

这是因为 Make 在工作的时候，每个目标的构建的单独判断所依赖的文件是否存在或其时间的。如果，foo.h 被修改，的确会触发 foo.c 的构建。不过这里我们只描述了 foo.c 和 foo.h 的依赖关系，而没有写任何构建指令。缺少构建指令时，默认是成功的。但是 foo.c 的时间并没有修改。这样在接下来的 foo.obj 构建过程中，foo.obj 的时间新于 foo.c （foo.c 未被修改过），故而 foo.h 的修改不会触发 foo.obj 的构建。

btw, 随着 Makefile 的复杂度增加，调试会是一个问题，上次我们介绍了 gmake 的 -n 参数，以观察执行流程。其实还有一个更为强大的 -d 参数，有兴趣的同学可以自己试试。

如何解决这个问题呢？一个苯办法是，当 foo.h 修改后，同时也更新 foo.c 的时间。在 *inx 下，有一个 touch 指令可以做这件事情。我们写作：

foo.c : foo.h
    touch $@

Windows 下没有 touch 指令，但是 copy 可以代劳：

foo.c : foo.h
    copy $@ +

这样做有些坏味道，明明是 foo.h 的修改，凭什么要更新 foo.c 的文件时间呢？所以，一般的做法是，让 foo.obj 直接依赖于 foo.h 。这样，我们的 Makefile 就变成了这样。

COBJS=foo.obj bar.obj

all : foobar.exe

clean :
    -del foobar.exe $(COBJS)

foobar.exe : $(COBJS)

foo.obj : foo.h

%.exe :
    link /out:$@ $^

$(COBJS) : %.obj : %.c
    cl /c 

如果我们需要随时开关调试状态怎么办？也就是说，希望更灵活的打开或关闭 /Zi （调试信息）/O2 (最大速度优化）这样的编译开关。通常会预留一个变量。

$(COBJS) : %.obj : %.c
    cl $(CFLAGS) /c $<

然后再最前面定义 CFLAGS =/Zi

我们还可以把最下面两段比较通用的规则放到一个独立文件 compile.mk 里，就好象 C 语言里的头文件那样。

CFLAGS=/O2    #优化
#CFLAGS=/Zi    #调试

COBJS=foo.obj bar.obj

all : foobar.exe

clean :
    -del foobar.exe $(COBJS)

foobar.exe : $(COBJS)

foo.obj : foo.h

include compile.mk

注意前面两行的 CFLAGS 的定义，它放置了一些我们以后可能会调整的编译选项。这里 # 表示注释，相当于 C++ 里的 //

再注意最后的 include 语句，它完成的工作非常类似于 C 语言中的 #include ，即把一段文本插入当前的 Makefile 文件。只不过，Make 的 include 比 C 语言下的强的多。它可以在 include 后跟多个文件名，而文件名也可以是一个变量。甚至 include 的文件本身也可以是一个目标文件。如果 include 的文件不存在时，可以调用自身对应的目标将其生成出来。这些用法，我们会在以后的时间里细细展开。对于 C 语言头文件的依赖关系的自动生成，通常需要类似的技术来实现。

附上 compile.mk 文件

%.exe :
    link /out:$@ $^

$(COBJS) : %.obj : %.c
    cl $(CFLAGS) /c $<

今天，我不想一直的围绕编译构建 C/C++ 工程谈下去。如前面所说，Make 可以帮助我们简化日常的许多工作。比如今天，我就碰到一个需求：要把一颗目录树下的所有图片文件转换成一种私有格式。

我们有自己的命令行转换工具，每次可以转换一个文件。（这种图片转换我想很多人都遇到过，对于通用图象格式间的互转，有一个非常好用的命令行工具，ImageMagick，google 即得）

我第一感觉想到的是使用命令行指令 for 。不知道的同学可以输入 for /? 查询。

for 可以帮我遍历目录树，并对每一个符合要求的文件做一段命令行指令。但是，这里有几个问题。我们需要转换的图片非常多，有上万个文件。全部转换一次非常长的时间。而转换工具有点小问题，中间如果出了故障，不方便继续。另一方面，我的台式机是双核的，很难利用两个核同时工作。

所以我写了一个 Makefile 来做这件事情。首先我用 for 指令生成了需要转换的文件名列表。

filelist:
    echo # > $@ && for /R %%I in (*.jpg) do echo LIST+=%%~pI%%~nI.dat >> $@

这小段代码会生成一个叫 filelist 的文件，里面有所有的 jpg 文件名。但是把扩展名 jpg 换成了我们的目标扩展名 .dat 。下面是一段针对转换工具的调用：

$(LIST) : %.dat : %.jpg
    convert $<

完整的 Makefile 最终是这样的，由于是随手写的，有些地方并不完备，但它可以快速工作。

include filelist

all: $(LIST)

filelist:
    echo # > $@ && for /R %%I in (*.jpg) do echo LIST+=%%~pI%%~nI.dat >> $@

$(LIST) : %.dat : %.jpg
    convert $< -o $@

运行 gmake ，转换工作开始了。一开始会显示 makefile:1: filelist: No such file or directory ，表示 filelist 找不到，无法 include 。但是没关系，接下来 Make 找到了 filelist 的构造方法，立刻构造出这个文件列表来。all 这个缺省目标就是依赖这个文件列表上的所有文件的。所以，工作可以随时用 Ctrl-C 停下来，下次运行时，gmake 将根据文件时间继续上次的工作。

这个 makefile 比较通用，其实可以放在任何地方，比如我把它塞在了 c:\tmp 下。需要转换那个目录下的所有 jpg 时，只需要进入那个目录，运行 gmake -f c:\tmp\makefile 即可。没错，gmake 可以用一个 -f 参数指定 makefile 文件的位置。这样，我们便有了一个方便的批量文件转换工具了。

怎么利用双核？太容易了。 gmake -j2 即可。-j2 表示用两个进程同时工作，如果是四核的机器，则可以 -j4 。打开 -j2 开关后，立刻可以发现 CPU 处于满负荷工作状态。短短几行代码就把这件事情搞定了。非常开心。

上一篇开篇，我们讲到了，如何用命令行分开编译 .c 文件，并把它们链接起来。这样做，可以使每次修改都可以让机器做最少的编译任务。对于小工程，这样做的意义不大。但是大工程，可能就能帮我们节约不少时间了。记住这一点，永远没有通用的最优方案。因为实施方案本身也是有成本的。我们只需要找到最直接最简单的方法就可以了。比如项目一开始，可以写一个最简单的 Makefile 文件，随着项目规模的扩大再逐步完善。

分开编译再链接这件事，人做起来都比较繁琐，把它教给机器去做，当然也会更繁琐。所以我没有在上一篇中详解。好学的同学应该会自己弄了，今天，我也来写写自己的方案。但在此之前，我们先梳理一下对 Make 的理解。

Make 是一个工作于非常简单的模式下的工具。它的内部有一张表，记录了目标文件之间的依赖关系。Makefile 就是用来描述这张依赖关系表的。对于依赖关系表的描述，用了一种非常简单的语法：

目标 : 依赖

这表示，"目标" 的构建依赖于 "依赖" 先构建出来。这里，"目标" 和 "依赖" 都是文件系统中的文件，而"依赖"本身也可以是一个"目标"。如果 "依赖" 的文件时间新于 "目标" 的文件时间，表示 "目标" 需要重新构建。如果 "目标" 文件不存在，也会触发这种构建过程。

一个目标可以有多个依赖，可以在 : 后以空格分开写上多个，比如：

目标 : 依赖1 依赖2 依赖3

这在我们前一篇中已经多次见过了。其实还有另一个规则，我们可以写：

目标 : 依赖1

目标 : 依赖2

这样分两行写，即，每次写 "目标 : 依赖" 都在依赖关系的依赖关系表中添加了一项。（关于同名的依赖添加的问题，以后我们在讨论）

举个例子：

a : b c

和

a : b
a : c

其实是等价的。

每个目标的构建方法并不是由 Make 内置功能完成的，Make 只是简单调用写在 "目标" 定义的下一行的若干命令行脚本而已。而每一行命令行脚本必须以 Tab 键开头。注意，如果你把目标的依赖关系分成若干行实现，只可以有一个地方定义构建脚本。

举例：

all : a
all : b

a :
    echo $@

b :
    echo $@

这样一个 Makefile 用 Make 运行后，会显示：

echo a
a
echo b
b

为什么呢？因为 Make 会找 Makefile 中定义的第一个目标，做为它这次的终极目标。在这里是 all 。all 依赖于 a 和 b 两个目标。由于你的工作目录下没有 a 和 b 两个文件，所以触发了 a 以及 b 的构建。而 a 的构建指令是 echo $@ ，$@ 指代了当前目标 "a" ，结果就执行了 echo a 。同样，b 文件的不存在，导致了 b 的构建，执行了 echo b 。

需要强调的是，echo 并不是 Make 的内置功能。echo 是 Windows 命令行指令（在 *nix 系统上，称为 shell 指令）。Make 只管忠实的执行那些相关的以 Tab 开始行内描述的命令行指令。目标的构建成功也不以目标文件是否正确生成为依据。而是以命令执行的结果是否为 0 。记得学 C 语言的时候，老师教你，main 函数得到正确结果时，应该 return 0 吧。这个 main 的 return 0 就是返回给系统用的。Make 通过检查这个返回值来觉得命令行指令是否被正确的执行。如果收到非 0 的返回值，整个 Make 的过程会被中断。当然，echo 这样的指令，一般都会返回 0 的。

注意，一个目标是否被正确构建，只取决于构建它的命令行指令是否正确的返回 0 ，而不取决于文件是否被创建出来或是被更新到最新的时间。在一次构建中，每个目标最多只会被构建一次。这是由于 Make 只对依赖关系表做一次简单的拓扑排序，然后就开始工作了。

同样，我们还可以让多个目标依赖同样的东西：

a b : c d

就等价于

a : c d
b : c d

现在我们可以看到，在 Makefile 里写 : 定义，其实就是在填写一张依赖关系表。每次的一个 : 都向表里追加一些项目。Make 工作的时候，先读完整个文件，把完整的依赖关系表建立好，再根据命令行指定的目标开始工作，如果在命令行不指定目标，默认就是 Makefile 里写的第一个目标了。

这样我们就好理解，除了 Makefile 里的第一个目标定义之外，所有的依赖关系描述都是无所谓书写的先后次序的。Make 只管向依赖关系表里添加表项，不会删除。原则上也不保证按依赖表中的次序先后来构建，如果你需要一个目标一定先于另一个目标构建，就需要显式的描述出依赖关系。

让我们回到早先的例子：从 foo.c 和 bar.c 构建出 foobar.exe 。并且要求 foo.c 和 bar.c 里若只修改了一个文件，就只编译新修改的那一个。

foobar.exe : foo.obj bar.obj
    link /out:$@ $^

foo.obj : foo.c
    cl /c $<

bar.obj : bar.c
    cl /c $<

先别急着编译，我们来看看如何调试 Makefile 文件。使用 gmake -n 看看，是不是显示了：

cl /c foo.c
cl /c bar.c
link /out:foobar.exe foo.obj bar.obj

如果显示的是，

gmake: `foobar.exe' is up to date.

那么就先 del foo.obj bar.obj foobar.exe 然后再看。

-n 参数可以让我们观察到底会执行些什么命令行指令，而不真的去执行它们。这对调试复杂的 Makefile 非常有用。

如果没有问题，就可以 gmake 构建出 foobar.exe 了。

如果你烦透了每次做一次实验都要手工清理一下 obj 和 exe 文件，那么可以把 del 指令也写在 Makefile 中。在上面的 Makefile 最后加上两行：

clean :
    -del foo.obj bar.obj foobar.exe

当然，你也可以偷懒写成 del *.obj *.exe

同学们会注意到，del 前有个减号。这个 - 是告诉 Make ，忽略掉后面这行指令的返回值，不要因为返回值非 0 而中断。什么时候 del 会返回非 0 值呢？自然是要删除的文件不存在啦。

现在你就可以通过 gmake clean 来清除目标文件了。或者用 gmake clean foobar.exe 来先清理再编译，这相当于我们在 IDE 中使用的 rebuild 指令。Make 的命令行可以跟多个目标，它会顺着构建这些目标。对于举一反三的同学，应该已经给 Makefile 加了一个 rebuild 目标了：

rebuild: clean foobar.exe

暂时先这么写着，以后我们会介绍更好的，更偷懒的写法。

最后给出一个云风当年初学 Make 时，犯过的一个错误。属于对 Make 理解不当造成的。

假设 foo.c 里 include 了一个 foo.h 文件，依赖关系应该怎么写？

在 Makefile 的最后，加上一行

foo.c : foo.h

这样行吗？

你可以试试，修改一下 foo.h ，然后 gmake 一下,看看有没有重新编译 foo.o 。为什么不能工作呢？留给同学们思考了。

使用 bat 的方式来构建项目有一个问题，那就是当项目慢慢增大时，效率受到影响。因为每次 build 一次，都要重新编译链接所有的源代码。而 C/C++ 从设计之初就考虑到节省编译时间，可以每个源文件独立编译的，然后最后在把分别编译出来的目标文件链接在一起。（关于编译和链接的概念，不明白的同学请自己 google ）下一步，我们可以每次只编译刚刚修改过的源文件，和那些没有修改过的源文件以前编译出来的目标链接在一起就够了。

早期的 C 编译器，但是将编译和链接过程分开由两个程序完成的（现在其实也是）。我们今天看到的类似微软的 cl 这种程序只是给独立的连接器加了个壳而已（gcc 也是这样）。下面我们来看怎样分开编译多个源文件，并链接它们。

如果只想编译一个 .c 文件，只需要在给 cl 加上参数 /c （ gcc 是加 -c ）。那么编译上一篇中提到的例子 foo.c ，即用命令行指令：

cl /c foo.c

我们可以看到，当前目录下生成了目标文件 foo.obj

我们可以用同样的方法生成 bar.obj 。即 cl /c bar.c

那么如何把 foo.obj 和 bar.obj 链接起来？还是用 cl 即可。

cl /Fefoobar foo.obj bar.obj

cl 这个壳会正确的识别输入文件的类型，做出对应的链接这个行为。我们也可以直接调用微软的链接器：Link 。

link /out:foobar.exe foo.obj bar.obj

注意，这里输出文件必须写全 .exe 后缀。

罗罗嗦嗦写了一大堆，主要是想加深以前不太明白这些的同学们的印象。如果是玩 IDE 的老鸟，其实在 IDE 的各种设置中，差不多也都看过这些了。关于编译器的命令行参数不记得不要紧。一则可以用 /? 看帮助；二还可以去 VS 的 IDE 中对应的设置菜单里看看，通常一个 IDE 菜单选项的修改，都对应了最终命令行参数的差别。生成 exe 还是生成 dll ；使用控制台模式，还是标准 Win32 程序；预定义些什么宏，打开调试信息或是开启编译优化，无所不在。

记住这些参数的写法并不容易，也没有必要。因为相对于编写代码，敲打这些编译开关只占很少的工作。但要记住，如何调用编译器去构建工程，这个步骤本身其实也是项目构建的一部分。亲手写过，也就多了一分了解。

编程之道在于，让机器做机器的事，人专注于人的思考。如果真的靠手键入每条编译指令，无疑让程序员去做了机器之事。把编译指令写入批处理（脚本）文件，仅仅只是节省了每次编译的重复劳动，并没有从根本上解脱。

在从 C 的源代码构建最终的执行文件这个流程中，哪些是人的创造，哪些是机器应行之事？显而易见，程序员应该做的是：

1. 教会机器，如何把一个 .c 文件编译成 .obj 文件。

2. 教会机器，如何把若干个 .obj 文件链接成 .exe 文件。

3. 告诉机器，你的项目由那些 .c 文件构成，最终你想生成一个叫什么名字的 .exe 文件。

其中前两步，对于大多数类似的项目来说是共同的，所以我们只用也只应该教机器一次。而第三步，提供一个文件列表和一个目标文件名给机器即可。

实现以上目标，显然我们需要额外的工具。IDE 的项目管理及构建模块是一个选择，但不是唯一的选择。IDE 对最为常见的构建需求做的相当不错。也就是说，IDE 完美的教会了机器前两个步骤，我们无须干预。但这件事情意义有多大呢？既然我们现在已经知道整件事情的流程手工怎么进行，完成它就有了无数的选择。教会机器做这前两件事情，只是一项一次性劳动。我们可以通过教授机器做这件事的过程，学会更多东西。而后举一反三去干更为复杂的工作。下面，云风将介绍一种叫做 MAKE 的工具。它是我们完成这个目的的第一个台阶。

为什么是 Make ？

我想说， make 只是诸多选择中的一个。它绝对不是最好的，但它是最容易理解的。make 以一种极其简单的规则运作，让程序员可以轻易看透它的实质。而简单的工具组合起来往往可以发挥出极大的能量。因为简单，所以 make 也很容易学习。你只需要掌握它很少的一部分功能，它就帮助你完成各种各样的工作。绝不仅仅是编译程序这么简单。你可以用它收发邮件、下载文件、制作安装包、运行单元测试，等等你能想的到的在你的机器上用命令行能够完成的所有事情。当然这些事情不用 make 也有别的方式去做，只是 make 用起来更方便。Make 会按你告诉它的事情的依赖关系，决定了做事情的前后次序，然后批量完成交给它的任务。如此而已。如果你用过 FreeBSD ，一定会爱上它的 ports 。需要什么软件，进入对应目录，make install 。下载、配置、编译、安装，一气呵成。这就是 make 的威力。

学会了 Make 后，你再接触别的项目构建工具，就不会有太多障碍。Make 做起来比较困难的事，也可以再高一个层次的工具来完成，比如 Automake 。我们要做的是，认识问题是什么，选择合适的工具，用程序员的方式解决它。

Make 有许多分支版本，细节使用起来各有差异。VS 里带了一个叫做 NMAKE 的小工具，是 Make 的一个旁支。我本来想从这个讲起，无奈用的不多，还是换成日常用的比较多的 GNU Make 吧。gmake 的内建指令也更为丰富，稍微熟悉一下，得心应手。更难得的是，在 Windows 下获得 gmake 非常方便，使用 Mingw 版的 gmake 即可，在 google 搜索 “mingw gnu make” 即可。其实不需要安装，它是一个绿色软件，一个独立的一百多K 的 gmake.exe 小程序就可以直接运行。

下面，云风假设你已经正确安装了 Mingw 版的 GNU Make （我的 Windows 系统上安装的版本是 3.81 ）。在命令行下，无论在什么目录下都可以直接输入 gmake 运行。（默认安装的 Gnu make 的执行文件名可能不叫这个名字，但你可以自己改个顺手的名字）

让我们开始吧。

还是在一个你可以随意做实验的目录，顶好是你已经创建了 foo.c bar.c 的那个目录下，新建一个叫做 Makefile 的文本文件。编译它，写上：

all :
    echo Hello World

这是你的第一个 Makefile ，输入请小心。第一行的 all: 应该顶格写，而第二行 echo 之前，必须有一个 Tab ，而不能用空格替代。即：第二行必须是 Tab 打头。

Tab 不是可以忽略的空白字符，并且是 Make 工作的关键。这个设定早就为许多人诟病，没有正确的输入 Tab ，也是许多 Make 初学者常见的错误。骂归骂，只能说这是一个历史原因造成的。好在一旦你习惯它，同样会觉得编写 Makefile 其实是非常顺手的。而且现在很多编辑器都可以让 Tab 明显的显示出来，而不会和空格混淆。

现在，运行 gmake ，你会看到它调用了命令行指令 echo Hello World ，回显了这行字符串。庆祝一下，你成功运行了自己编写的第一个 Makefile 。

Make 的一切设计都是为了简单、快捷。你把要做的事情写在一个文件中，运行 gmake 去跑这些任务。按通常的设计，gmake 应该跟一个任务文件的文件名，指定跑哪个文件。但是为了简洁，gmake 默认去找当前目录下的名为 Makefile 的文件了。至于你想把这些任务放在别的文件中，可以通过 gmake 的参数控制。有兴趣的同学可以按 Gnu 软件的习惯，通过 gmake --help 查询。

光能显示一行 Hello World 显然离题万里。接下来我们看看让 gmake 帮我们编译程序。不要删除前面的 Makefile 文件，再后面追加几行：

foobar.exe :
    cl /Fefoobar foo.c bar.c

记住第二行开头的 Tab 不要敲漏了。

现在你的 Makefile 文件看起来应该是这样：

all :
    echo Hello World

foobar.exe :
    cl /Fefoobar foo.c bar.c

我们再运行一下 gmake foobar.exe 看看：gmake 调用了你写好的 cl 指令，编译出了 foobar.exe 这个文件。

OK，大家应该看出点什么。Makefile 比传统的 bat 批处理文件多了点功能。它可以把多个任务放在一个文件里，而不需要我们写多个文件。为了区分任务，我们在命令行指定要做什么。

那些顶行写的文本，如果由一个单词加一个冒号开始。这个单词就被称为一个目标。gmake 目标，就可以做对应的任务了。而 gmake 会去做什么呢？自然由目标定义的下面几行决定。所有以 Tab 开头的文本行，定义了完成这个目标应该执行的命令行指令。gmake 会运行目标定义之下一直到下一个目标定义之间的所有指令。（注：Make 并不会保证这些指令的执行次序，虽然原则上是按你书写次序执行。这可以让 Make 使用多个 CPU 加快运行成为可能）

当我们在命令行输出 gmake all ，它就 echo Hello World ；而输入 gmake foobar.exe 它就调用 cl 去生成 foobar.exe 。如果没有直接输入 gmake 而不跟任何目标参数。它会自动寻找文件里的第一个目标。（而 Makefile 编写的惯例，我们通常把第一个目标起名字为 all ，这仅仅是一个惯例而已）

多试几次看看。

第 2 次运行 gmake foobar.exe 你会发现，gmake 报告：

gmake: `foobar.exe' is up to date.

而拒绝再次编译。

没错，这就是 Make 为数不多的原则之一：一旦目标已经存在，就直接跳过任务。

所有的目标，都被 Make 认为是一个文件，它的规则就是，如果目标文件存在，就认为事情已经做完。除非……

让我们修改一下 Makefile 把 foobar.exe : 这行改成

foobar.exe : foo.c bar.c

然后修改一下 foo.c 存盘，再运行 gmake foobar.exe 试试？又重新编译了对吧。

这就是 Make 的第二条原则：目标 : 后面以空格写上它所依赖的其它目标。如果所依赖目标存在，且比目标本身的时间新，就重新构键一次目标。

由于我们修改了 foo.c 导致了 foo.c 这个文件（对 Make 来说是一个目标，只不过没有构建这个目标的方法而已，只能靠用户自己编辑生成）比 foobar.exe 更新。foobar.exe 依赖 foo.c ，所以触发了 foobar.exe 的构建方法。

同样，我们可以让 all 依赖与 foobar.exe 。这样 gmake all （或省略 all 不写，因为 all 是第一个目标）时，由于不存在 all 这个文件，而触发 foobar.exe 的构建流程。

接下来，我们回头来看看自己编写的这个 Makefile 文件。现在大约是这个样子：

all : foobar.exe
    echo Hello World

foobar.exe : foo.c bar.c
    cl /Fefoobar foo.c bar.c

第 2 个目标 foobar.exe 的编写非常的累赘。程序员的直觉告诉我们，信息的重复不是一个好味道。那么让我们来修改一下。

foobar.exe : foo.c bar.c
    cl /Fe$@ $^

这样是不是味道好点了？$@ 和 $^ 都是 Make 的内设变量，也可以看成是一种类似 C 语言中宏的东西。$@ 在指令被运行时，被宏替换为目标，而 $^ 被宏替换为所有的依赖目标，即冒号后面的那一长串东西。同样常用的还是 $< ，可以替换所依赖的第一个目标。

今天已经写的足够多了。没接触过 Make 工具的同学应该能初窥门径了。没错，从现在已经介绍的知识来看，Make 并没有为我们节省太多体力，甚至还多敲了许多字符，今天快结束时，居然还要多记几个诸如 $@ 这样古怪的符号。而做到的事情离我们的目标还很远。

没关系，云风会带着你渐入佳境的，那么，且听下回分解。