Make一般是在Unix环境下使用的自动化编译工具。他本身不是编译器，而是将众多C/C++源文件组织起来，确定其编译方式和编译顺序的工具。一旦我们写好的Makefile配置文件，那么无论多么复杂的工程我们都可以用一条make命令来解决。事实上，尽管通常和C/C++搭配起来使用，make也能应用到其他的编程语言之中。
在使用make过程中的第一个核心问题是处理文件依赖的问题。例如：
foo.o : foo.c defs.h # foo模块
cc -c -g foo.c
这里foo.o依赖于foo.c和defs.h。当后面两个文件发生变化时，make会自动运行cc -c -g foo.c命令更新foo.o文件。但是，随着项目扩大。这种文件之间的依赖关系会变得非常复杂，一个小的改动可能会涉及到众多依赖关系的修改。因此有必要在项目的开始就引入自动构建依赖关系的工具链。
在跟我一起写Makefile:书写规则这篇教程中，提到了编译器的一个特性：大多数的C/C++编译器都支持一个"-M"的选项，即自动寻找源文件中包含的头文件，并生成一个依赖关系。例如如果我们执行
cc -M main.c
其输出是：
main.o: main.c defs.h
注意如果你用的是GNU的C/C++编译器，你得用"-MM"参数，不然，"-M"参数会把一些标准库头文件也引入进来。
这篇教程里面详细阐述了如果在Makefile中使用这一特性的方法，综合而来就是：
# 对于每个.c源文件，建立一个描述其依赖关系的.d依赖文件
%.d: %.c
@set -e; rm -f $@; \
$(CC) -M $(CPPFLAGS) $< > $@.$$$$; \
sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \
rm -f $@.$$$$
上述命令中
sed命令的作用是在依赖关系对中，在左侧加上.d文件本身。即
将main.o: main.c defs.h转换成
main.o main.d : main.c defs.h
然后将生成的依赖关系文件include进来
sources = foo.c bar.c
include $(sources:.c=.d)
在教程中还提到，这个include要放在默认目标之后，避免include载入的文件的目标替换了默认目标。
走完上面的流程，会得到一个类似的如下内容的文件：
%.d: %.c
@set -e; rm -f $@; \
$(CC) -M $(CPPFLAGS) $< > $@.$$$$; \
sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \
rm -f $@.$$$$
sources = main.c foo.c bar.c
objs = $(sources:.c=.o)
include $(sources:.c=.d)
main: $(objs)
$(CC) -o main $(objs)
.PHONY : clean
clean:
@rm -f *.d *.o
@rm -f ./main
不过按照这个Makefile第一次执行的时候会产生一个问题：第一次执行时，.d文件尚未生成，这里的include导入的文件不存在，会产生如下的错误信息
Makefile:8: main.d: No such file or director
make: *** No rule to make target 'main.d'. Stop.
最后是通过面向google的debug找到了Autodependencies with GNU make这篇2001年的文章，细致地阐述了这个问题。解决的关键在于在include前面添加一个dash（-），其作用是：如果include的对象不存在，make继续执行，后续make会自动生成.d文件，然后执行include。这篇新的教程提供的完整Makefile示例如下（和前面的形式有不同，但是思路是一致的）：
OBJS := foo.o bar.o
# link
proggie: $(OBJS)
gcc $(OBJS) -o proggie
# pull in dependency info for *existing* .o files
-include $(OBJS:.o=.d)
# compile and generate dependency info
%.o: %.c
gcc -c $(CFLAGS) $*.c -o $*.o
gcc -MM $(CFLAGS) $*.c > $*.d
# remove compilation products
clean:
rm -f proggie *.o *.d
网友评论