在一些大型的项目中，它的结构是很复杂的。比如下面这个
我们来分析下这个项目的架构，项目被划分为多个不同模块。每个模块的代码用一个文件夹进行管理，文件夹由 inc，src，makefile 组成；每个模块的对外函数声明统一放置于 common/inc 中，如：common.h xxxfunc.h。
那么我们需要打造的编译环境是：1、源码文件夹在编译时不能被改动（只读文件夹）；2、在编译时自动创建文件夹（build）用于存放编译结果；3、编译过程中自动生成依赖关系，自动搜索需要的文件；4、每个模块可以拥有自己独立的编译方式；5、支持调试版本的编译选项。
我们看看解决方案是怎样设计的
第 1 阶段：将每个模块中的代码编译成静态库文件，如下
第 2 阶段：将每个模块的静态库文件链接成最终可执行程序，如下
那么第一阶段完成的任务就是完成可用于各个模块编译的 makefile 文件，每个模块的编译结果为静态库文件（.a 文件）。那么关键的实现要点就是：a> 自动生成依赖关系（gcc -MM）；b> 自动搜索需要的文件（vpath）；c> 将目标文件打包为静态库文件（ar crs）。我们来看看模块的 makefile 的构成，如下
我们来看看这个 makefile 是怎样编写的
.PHONY : all DIR_BUILD := /mnt/hgfs/winshare/mentu/make1/14/build DIR_COMMON_INC := /mnt/hgfs/winshare/mentu/make1/14/common/inc DIR_SRC := src DIR_INC := inc TYPE_SRC := .c TYPE_INC := .h TYPE_OBJ := .o TYPE_DEP := .dep AR := ar ARFLAGS := crs CC := gcc CFLAGS := -I$(DIR_INC) -I$(DIR_COMMON_INC) ifeq ($(DEBUG),true) CFLAGS += -g endif MODULE := $(realpath .) MODULE := $(notdir $(MODULE)) DIR_OUTPUT := $(addprefix $(DIR_BUILD)/, $(MODULE)) OUTPUT := $(MODULE).a OUTPUT := $(addprefix $(DIR_BUILD)/, $(OUTPUT)) SRCS := $(wildcard $(DIR_SRC)/*$(TYPE_SRC)) OBJS := $(SRCS:$(TYPE_SRC)=$(TYPE_OBJ)) OBJS := $(patsubst $(DIR_SRC)/%, $(DIR_OUTPUT)/%, $(OBJS)) DEPS := $(SRCS:$(TYPE_SRC)=$(TYPE_DEP)) DEPS := $(patsubst $(DIR_SRC)/%, $(DIR_OUTPUT)/%, $(DEPS)) vpath %$(TYPE_INC) $(DIR_INC) vpath %$(TYPE_INC) $(DIR_COMMON_INC) vpath %$(TYPE_SRC) $(DIR_SRC) -include $(DEPS) all : $(OUTPUT) @echo "Success! Target ==> $(OUTPUT)" $(OUTPUT) : $(OBJS) $(AR) $(ARFLAGS) [email protected] $^ $(DIR_OUTPUT)/%$(TYPE_OBJ) : %$(TYPE_SRC) $(CC) $(CFLAGS) -o [email protected] -c $(filter %$(TYPE_SRC), $^) $(DIR_OUTPUT)/%$(TYPE_DEP) : %$(TYPE_SRC) @echo "Creating [email protected] ..." @set -e; $(CC) $(CFLAGS) -MM -E $(filter %$(TYPE_SRC), $^) | sed 's,\(.*\)\.o[ :]*,$(DIR_OUTPUT)/\1$(TYPE_OBJ) [email protected] : ,g' > [email protected]
在 14 文件夹下创建 build 文件夹用于存放生成的文件，在里面继续创建 common 文件夹用于存放 common 相关的编译产生的文件，我们来看看编译结果是怎样的
我们看到已经产生自动依赖的 .dep 文件，和打包生成的 .a 文件了。下来我们将此 makefile 文件直接复制到 main 和 module 文件夹下，看看是否也可以生成相关文件呢（在 build 文件夹下创建 main 文件夹）
我们看到已经产生自动依赖的 .dep 文件，和打包生成的 .a 文件了。下来我们看看复制到 module 文件夹是否也可以生成相关文件呢（在 build 文件夹下创建 module 文件夹）
现在我们的第一阶段的模块自动编译的 makefile 已经编写完成，功能也都实现了。下来我们看看第二阶段的编写，那么第二阶段的任务如下：1、完成编译整个工程的 makefile 文件；2、调用模块 makefile 编译生成静态库文件；3、链接所有模块的静态库文件，最终得到可执行程序。格式如下
那么其实现的关键要点有哪些呢？1、如何自动创建 build 文件夹以及子文件夹？我们是通过 mkdir 命令来实现的；2、如何进入每一个模块文件夹进行编译？通过 cd 命令来实现；3、编译成功后如何链接所有模块静态库？通过 gcc 命令来实现。那么现在最大的问题就是我们如何确定这个项目中有几个模块？在一般的项目中的各个模块在设计阶段就已经基本确定，因此，在之后的开发过程中不会频繁随意的增加或减少。
下来我们来看看解决方案是怎样的？1、定义变量保存模块名列表（模块名变量）；2、利用 Shell 中的 for 循环遍历模块名变量；3、在 for 循环中进入模块文件夹进行编译；4、循环结束后链接所有的模块静态库文件。下来我们看看在 makefile 中是如何 嵌入 Shell 的 for 循环呢，如下
我们先来试试 Shell 中的 for 循环，代码如下
MODULES="common main module" for dir in $MODULES; do echo $dir done
编译结果如下
我们看到已经正确的输出三个变量名了。下来我们来看看在 makefile 中它是如何执行的，代码如下
MODULES := common main module test : @set -e; for dir in $(MODULES); do echo $$dir; done
我们来看看编译结果，是否如我们所期望的那样正确输出三个变量名呢？
我们看到在 makefile 中已经正确输出 Shell 中的 for 循环了。在 makefile 中嵌入 Shell 代码时，如果需要使用 Shell 变量的值，必须在变量名前加上 $$（例：$$dir）！我们来看看工程 makefile 中的构成都有哪些呢？如下
下来我们来看看 compile 的代码应该怎么写
.PHONY : all compile MODULES := common main module MKDIR := mkdir RM := rm -rf DIR_PROJECT := $(realpath .) DIR_BUILD := build DIR_BUILD_SUB := $(addprefix $(DIR_BUILD)/, $(MODULES)) all : @echo "Success!" compile : $(DIR_BUILD) $(DIR_BUILD_SUB) @echo "Begin to compile ..." @set -e; for dir in $(MODULES); do cd $$dir && $(MAKE) all DEBUG:=$(DEBUG) && cd .. ; done @echo "Compile Success!" $(DIR_BUILD) $(DIR_BUILD_SUB) : $(MKDIR) [email protected]
我们来看看编译结果
我们看到已经正确编译出 .a 文件了，如下
下来我们看看怎么实现链接的，链接时应注意：a> gcc 在进行静态库链接时必须遵循严格的依赖关系，如 gcc -o app.out x.a y.a z.a。其中的依赖关系必须为：x.a->y.a，y.a->z.a，默认情况下遵循自左向右的依赖关系；b> 如果不清楚库间的依赖，可以使用 -Xlinker 自动确定依赖关系，如 gcc -o app.out -Xlinker "-(" z.a y.a x.a -Xlinker "-)"。下来我们来看看最后的 makefile 的代码是怎样编写的
.PHONY : all compile link clean rebuild
MODULES := common main module
MKDIR := mkdir
RM := rm -rf
CC := gcc
LFLAGS :=
DIR_PROJECT := $(realpath .)
DIR_BUILD := build
DIR_BUILD_SUB := $(addprefix $(DIR_BUILD)/, $(MODULES))
MODULE_LIB := $(addsuffix .a, $(MODULES))
MODULE_LIB := $(addprefix $(DIR_BUILD)/, $(MODULE_LIB))
APP := app.out
APP := $(addprefix $(DIR_BUILD)/, $(APP))
all : compile $(APP)
@echo "Success! Target ==> $(APP)"
compile : $(DIR_BUILD) $(DIR_BUILD_SUB)
@echo "Begin to compile ..."
@set -e; for dir in $(MODULES); do cd $$dir && $(MAKE) all DEBUG:=$(DEBUG) && cd .. ; done
@echo "Compile Success!"
link $(APP) : $(MODULE_LIB)
@echo "Begin to link ..."
$(CC) -o $(APP) -Xlinker "-(" $^ -Xlinker "-)" $(LFLAGS)
@echo "Link Success!"
$(DIR_BUILD) $(DIR_BUILD_SUB) :
$(MKDIR) [email protected]
clean :
$(RM) $(DIR_BUILD)
rebuild : clean all
我们来看看链接的效果
我们看到已经链接成功了，并且可以正确的运行可执行程序 app.out。我们来直接 make 试试是否可以生成可执行程序。
我们看到已经生成可执行程序 app.out，并且能够成功运行。我们的 makefile 算是编写完成了，那么当前整个项目的 makefile 是否存在潜在的问题？是否需要重构呢？问题一：我们在之前的模块中的 makefile 路径都是写死的，一旦项目文件夹移动，编译必将失败！如下
解决方案：a> 便是在工程 makefile 中获取项目的源码路径；b> 根据项目源码路径，拼接得到编译文件夹的路径（DIR_BUILD），拼接得到全局包含路径（DIR_COMMON_INC）；c> 通过命令行变量将路径传递给模块 makefile。下来我们看看改过后的代码
.PHONY : all compile link clean rebuild
MODULES := common main module
MKDIR := mkdir
RM := rm -rf
CC := gcc
LFLAGS :=
DIR_PROJECT := $(realpath .)
DIR_BUILD := build
DIR_COMMON_INC := common/inc
DIR_BUILD_SUB := $(addprefix $(DIR_BUILD)/, $(MODULES))
MODULE_LIB := $(addsuffix .a, $(MODULES))
MODULE_LIB := $(addprefix $(DIR_BUILD)/, $(MODULE_LIB))
APP := app.out
APP := $(addprefix $(DIR_BUILD)/, $(APP))
all : compile $(APP)
@echo "Success! Target ==> $(APP)"
compile : $(DIR_BUILD) $(DIR_BUILD_SUB)
@echo "Begin to compile ..."
@set -e; for dir in $(MODULES); do cd $$dir && $(MAKE) all DEBUG:=$(DEBUG) DIR_BUILD:=$(addprefix $(DIR_PROJECT)/, $(DIR_BUILD)) DIR_COMMON_INC:=$(addprefix $(DIR_PROJECT)/, $(DIR_COMMON_INC)) && cd .. ; done
@echo "Compile Success!"
link $(APP) : $(MODULE_LIB)
@echo "Begin to link ..."
$(CC) -o $(APP) -Xlinker "-(" $^ -Xlinker "-)" $(LFLAGS)
@echo "Link Success!"
$(DIR_BUILD) $(DIR_BUILD_SUB) :
$(MKDIR) [email protected]
clean :
$(RM) $(DIR_BUILD)
rebuild : clean all
我们直接删除掉三个模块中的绝对路径，看看编译结果是否和之前一样
我们看到编译是成功的。问题二：所有模块 makefile 都是相同的（复制粘贴），当模块 makefile 需要改动时，将涉及多处相同的改动！解决方案：a> 将模块 makefile 拆分为两个模板文件，mod-cfg.mk 用于定义可能改变的变量，mod-rule.mk 用于定义相对稳定的变量和规则，mod-cmd.mk 用于定义命令行相关的变量；b> 默认情况下，模块 makefile 复用模板文件实现功能（include）。
原文地址：http://blog.51cto.com/12810168/2131561