首页 > 代码库 > makefile实例（3）-多个文件实例优化
makefile实例（3）-多个文件实例优化
我们先看一下make是如何工作的
在默认的方式下，也就是我们只输入make命令。那么，
1、make会在当前目录下找名字叫“Makefile”或“makefile”的文件。
2、如果找到，它会找文件中的第一个目标文件（target），在上面的例子中，他会找到“edit”这个文件，并把这个文件作为最终的目标文件。
3、如果edit文件不存在，或是edit所依赖的后面的 .o 文件的文件修改时间要比edit这个文件新，那么，他就会执行后面所定义的命令来生成edit这个文件。
4、如果edit所依赖的.o文件也不存在，那么make会在当前文件中找目标为.o文件的依赖性，如果找到则再根据那一个规则生成.o文件。（这有点像一个堆栈的过程）
5、当然，你的C文件和H文件是存在的啦，于是make会生成 .o 文件，然后再用 .o 文件生命make的终极任务，也就是执行文件edit了。
这就是整个make的依赖性，make会一层又一层地去找文件的依赖关系，直到最终编译出第一个目标文件。在找寻的过程中，如果出现错误，比如最后被依赖的文件找不到，那么make就会直接退出，并报错，而对于所定义的命令的错误，或是编译不成功，make根本不理。make只管文件的依赖性，即，如果在我找了依赖关系之后，冒号后面的文件还是不在，那么对不起，我就不工作啦。
通过上述分析，我们知道，像clean这种，没有被第一个目标文件直接或间接关联，那么它后面所定义的命令将不会被自动执行，不过，我们可以显示要make执行。即命令——“make clean”，以此来清除所有的目标文件，以便重编译。
于是在我们编程中，如果这个工程已被编译过了，当我们修改了其中一个源文件，比如file.cpp，那么根据我们的依赖性，我们的目标file.o会被重编译 （也就是在这个依性关系后面所定义的命令），于是file.o的文件也是最新的啦，于是file.o的文件修改时间要比edit要新，所以edit也会被 重新链接了（详见edit目标文件后定义的命令）。
源代码见上一节例子。
1，makfile优化之一-使用变量
定义变量：VAR = VALUE
使用变量：$(VAR)
上节的makefile中的语句中，[.o]文件的字符串被重复了3次，这个可以优化
edit : main.o kde.o command.o display.o insert.o search.o utils.o files.o g++ -o edit main.o kde.o command.o display.o insert.o search.o utils.o files.oclean : rm edit main.o kde.o command.o display.o insert.o search.o files.o utils.o -rf
优化后的makefile，是不是感觉清爽了一些了？
objects = main.o kde.o command.o display.o insert.o search.o utils.o files.oedit : $(objects) g++ -o edit $(objects)main.o : main.cpp defs.h g++ -c main.cppkde.o : kde.cpp defs.h command.h g++ -c kde.cppcommand.o : command.cpp defs.h command.h g++ -c command.cppdisplay.o : display.cpp defs.h buffer.h g++ -c display.cppinsert.o : insert.cpp defs.h buffer.h g++ -c insert.cppsearch.o : search.cpp defs.h buffer.h g++ -c search.cppfiles.o : files.cpp defs.h buffer.h command.h g++ -c files.cpputils.o : utils.cpp defs.h g++ -c utils.cppclean : rm edit $(objects) -rf
2，优化之二-借助自动推导
GNU的make很强大，它可以自动推导文件以及文件依赖关系后面的命令，于是我们就没必要去在每一个[.o]文件后都写上类似的命令，因为我们的make会自动识别，并自己推导命令。
只要make看到一个[.o]文件，它就会自动的把[.c]文件加在依赖关系中，如果make找到一个whatever.o，那么whatever.c就会是whatever.o的依赖文件。并且 cc -c whatever.c 也会被推导出来，这种方法是make的“隐晦规则”。
于是，我们的makefile再也不用写得这么复杂。
objects = main.o kde.o command.o display.o insert.o search.o utils.o files.oedit : $(objects) g++ -o edit $(objects)main.o : main.cpp defs.h kde.o : kde.cpp defs.h command.h command.o : command.cpp defs.h command.h display.o : display.cpp defs.h buffer.h insert.o : insert.cpp defs.h buffer.h search.o : search.cpp defs.h buffer.h files.o : files.cpp defs.h buffer.h command.h utils.o : utils.cpp defs.h clean : rm edit $(objects) -rf
3，优化之三-深层自动推导
看到那堆[.o]和[.h]的依赖就有点不爽，那么多的重复的[.h]，现在我们把它们收拢起来。
根据上一节呈现出来的头文件依赖关系，我们优化如下：
objects = main.o kde.o command.o display.o insert.o search.o utils.o files.oedit : $(objects) g++ -o edit $(objects)$(objects) : defs.hkbe.o command.o files.o : command.hdisplay.o insert.o search.o files.o :buffer.hclean : rm edit $(objects) -rf
这种风格，让我们的makefile变得很简单，但我们的文件依赖关系就显得有点凌乱了。鱼和熊掌不可兼得。看各人所好了。
4，优化之四-清空规则
每个Makefile中都应该写一个清空目标文件（.o和执行文件）的规则，这不仅便于重编译，也很利于保持文件的清洁。这是一个“修养”（呵呵，还记得我的《编程修养》吗）。一般的风格都是：
clean:
rm edit $(objects)
更为稳健的做法是：
.PHONY : clean
clean :
-rm edit $(objects)
前 面说过，.PHONY意思表示clean是一个“伪目标”，。而在rm命令前面加了一个小减号的意思就是，也许某些文件出现问题，但不要管，继续做后面的事。当然clean的规则不要放在文件的开头，不然，这就会变成make的默认目标，相信谁也不愿意这样。不成文的规矩是——“clean从来都是放在文件的最后”。
objects = main.o kde.o command.o display.o insert.o search.o utils.o files.oedit : $(objects) g++ -o edit $(objects)$(objects) : defs.hkbe.o command.o files.o : command.hdisplay.o insert.o search.o files.o :buffer.h.PHONY : cleanclean: -rm edit $(objects)
makefile实例（3）-多个文件实例优化