一.项目的目录结构

分析 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也需考虑复用性和维护性等基本程序特性