一.项目的目录结构

分析
A.项目被划分为多个不同模块
1.每个模块的代码用一个文件夹进行管理--文件夹由inc,src,makefille构成
2.每个模块的对外函数声明统一放置于common/inc中--如:commom.h xxxfunc.h
B.需要打造的编译环境
1.编码文件夹在编译时不能被改动
2.在编译时自动创建文件夹用于存放编译结果
3.编译过程中能够自动生成依赖关系，自动搜索需要的文件
4.每个模块可以拥有自己独立的编译方式
5.支持调试版本的编译选项
C.解决方案的设计
第1阶段:将每个模块中的代码编译成静态文件

第2阶段:将每个模块的静态文件链接成最终可执行程序

二.实现

第一阶段：
1.完成可用于各个模块编译的makefile文件
2.每个模块的编译结果为静态库文件(.a文件)
关键的实现要点：
1.自动生成依赖关系(gcc -MM)
2.自动搜索需要的文件(vpath)
3.将目标文件打包为静态库文件(ar crs)

编译实现

对应项目的目录结构，对应的文件夹下包含着相应的头文件和源文件

运行的结果如图所示

在module文件夹和main文件夹下分别新建makefile，复制当前的makefile，在build新建module和main的空文件夹,运行make all命令都可以生成.o文件，实现了各个模块编译的makefile文件
第二阶段任务:
1.完整编译整个工程的makefile文件
2.调用模块makefile编译生成静态库文件
3.链接所有模块的静态库文件，最终得到可执行程序

关键的实现要点
1.如何创建build文件夹以及子文件夹
2.如何进入每一个模块文件夹进行编译
3.编译成功后如何链接所有模块静态库
解决方案设计
1.定义变量保存模块名列表
2.利用Shell中的for循环遍历模块名变量
3.在for循环在进入模块文件夹进行编译
4.循环结束后链接所有的模块静态库文件

链接的注意事项
A.gcc在进行静态库链接时必须遵循严格的依赖关系
1.gcc -o app.out x.a y.a z.a《==》其中的依赖关系必须为:x.a->y.a,y.a->z.a;默认情况下遵循自左向右的依赖关系
2.如果不清楚库间的依赖，可以使用-Xlinker自动确定依赖关系
gcc -o app.out -Xlinker(x.a y.a z.a -Xlinker)
运行代码及运行结果图如图所示

在makefile中可以知道 可以一步一步的进行make也可以一步完成makefile


结果对比图

三. 可能出现的问题
A.所有模块makefile中使用的编译路径均为写死的绝对路径，一旦项目文件夹移动，编译必将失败

解决方案：
1.在工程makefile中获取项目的源码路径
2.根据项目源码路径：a：拼接得到编译文件的路径(DIR_BUILD),b：拼接得到全局包含路径(DIR_COMMON_INC)
3.通过定义命令行变量将路径传递给模块makefile
代码的实现：
对之前的代码进行该动的地方(红线进行了标出)

运行的结果

通过对每个文件夹的makefile进行修改 对每个makefile中的每个绝对路径进行删除 发现运行的结果没有改变‘

#####################################
B.所有模块makefile的内容完全相同
当模块makefile需要该动时，将涉及多处相同的改动
解决方案：
1.将模块makefile拆分为两个模板文件
mod-cfg.mk 定义可能改变的变量
mod-rule.mk 定义相对稳定的变量和规则
2.默认情况下
模块makefile复用模板文件实现功能（include）
关键问题:
1.模块makefile如何知道模板文件的具体位置
2.解决方案：通过命令行变量进行模板文件位置的传递
实现:

.运行结果如图：

四 :小结
1.大型项目的编译环境是由不同makefile构成的
2.编译环境的设计需要依据项目的整体构架设计
3.整个项目的编译过程可以分解为不同阶段
4.根据不同的阶段有针对性的对makefile进行设计
5.makefile也需考虑复用性和维护性等基本程序特性