QC AMSS BUILD SYSTEM

总算把AMSS这套Makefile整完了，比起Android来QC这套Makefile还是比较烂的，架构不清晰，很多重复的规则，一个模块要 不要加入需要判断三次，模块的路径上判断一次，模块的*.min要判断一次，模块的OBJ文件上还要判断一次，而且基本target都加了强制目标作为依 赖，导致很多目标每次编译时都被强制更新，间接导致了每次编译的时间都特别的长。

     AMSS把QCSBL/OEMSBL/CFG_DATA/PARTITION/AMSS/FLASH_TOOL用MAKE －C来分开编译，这在实现上比Android那种一切皆模块简单多了，不过个人觉得这样很容易导致父MAKE和子Make变量之间的混乱，尤其涉及到这么 多export变量的时候。闲话就不多说了，看看这套Make吧～～

     虽然说架构不清晰，但是这套Make还是有一个比较通用的系统结构的：

 

   首先是定义一些全局变量，这些变量大多数都是路径啊，以及与芯片和编译器相关的一些FLAG，还有一个最重要的全局变量就是USES_XXX，这种类型的 变量定义我们最后需要将什么模块编译进系统。定义完这些全局变量之后下面一个就是编译器（RVCT）相关的一些编译选项，比如说CPU结构啊，编译是时间 优先还是空间优先啊以及一些初始化的CFLAGS/AFLAGS/LCFLAGS等等。全局变量以及编译器选定以后下面就是选择要编译的模块，QC把模块 放在3个部分，一个是模块的路径，另外一个是模块的本地Make文件*.min，最后一个就是模块要生成的OBJ文件。个人觉得这样分开的结果导致模块相 当乱，什么东西都要来三次，效率还是比较低的。了解需要编译的模块以后最后就是生成最终目标所需要的一系列规则了，包括生成.o和最终的IMG的一系列规 则。下面是一个稍微比较消息的描述：

 

     AMSS make的最终目标是dmss，定义在dmss_rules.min里面，而它最重要的一个依赖boot是定义在boot_targets_nonsec.min里面，这个boot定义了大部分img生成的规则：

        

     除了amss.mbn和amsshd.mbn是在DMSS主Make中生成的以外，其他的IMG都是在子Make中生成的。partition.mbn是相对简单的，oemsbl和qcsbl基本上采用了和DMSS实现的相同的架构，我这里只是简单的画了下：

   

 

 appsbl因为我们直接使用android的LK，所以不需要，直接在dmss_rules.min将其注释掉就好了。基本上到这里这套 MAKE已经很清晰了，下面我们来看看如何判断一个模块是否被编译，当然了解了一个模块是否被编译我们也能清楚的知道如何增加和去除一个模块。