buildc 0.2.1版本是一个bugfix版本，修正了两个重要问题。

* 修正执行buildc pack –cmode=32-bit时无法创建32位安装包的问题

之前的buildc pack命令在打包安装程序时忽略了–cmode这个选项，这样即便传入32-bit这个参数，打出的安装包中的应用程序依旧是64位编译的。这次修正了这个问题，让buildc真正支持打32位程序的安装包。

* 修正buildc cache相关命令与cmode选项结合的问题

其实这是一个因当初设计考虑不周而遗留下来的问题。最初考虑buildc在一个Workplace下面要么只管理64-bit的库，要么只管理 32-bit的库，没有考虑支持两者都cache以及两者可分别管理。而现实开发中，我们的开发人员在自己的workplace下既有64位程序，也有 32位程序，这样在用到buildc时反倒比较麻烦，因此这次将buildc cache的管理命令与–cmode选项结合，做了新的定义：

   – buildc cache init ： 根据.buildc.rc初始cache本地库，既初始下载64-bit库，也下载32-bit库；
   – buildc cache init –cmode=64-bit : 根据.buildc.rc初始cache本地库，只初始下载64-bit库；
   – buildc cache init –cmode=32-bit : 根据.buildc.rc初始cache本地库，只初始下载32-bit库；

   – buildc cache update ：根据.buildc.rc更新本地cache库，既更新64-bit库，也更新32-bit库；
   – buildc cache update –cmode=64-bit：根据.buildc.rc更新本地cache库，只更新64-bit库；
   – buildc cache update –cmode=32-bit：根据.buildc.rc更新本地cache库，只更新32-bit库；

   – buildc cache upgrade ：根据最新变更的.buildc.rc升级本地cache库，既升级64-bit库，也升级32-bit库；
   – buildc cache upgrade –cmode=64-bit：根据最新变更的.buildc.rc升级本地cache库，只升级64-bit库；
   – buildc cache upgrade –cmode=32-bit：根据最新变更的.buildc.rc升级本地cache库，只升级32-bit库；

   – buildc cache remove ：根据.buildc.rc配置，删除本地cache库，既删除64-bit库，也删除32-bit库；
   – buildc cache remove –cmode=64-bit：根据.buildc.rc配置，删除本地cache库，只删除64-bit库；
   – buildc cache remove –cmode=32-bit：根据.buildc.rc配置，删除本地cache库，只删除32-bit库。

buildc的演进先后经历了构建管理和安装包工程管理两个阶段。其中buildc的构建管理功能在项目中应用较早，目前相对稳定可靠。但其支持的安装包工程是直到最近才被大家所正式使用的。不出意料，大家在使用过程发现了一些问题，于是我们也是边用边改。

目前一个setup工程一般具有类似如下源码组织结构：

distributions/
setup.cfg
src/
    – README
    – app/
    – conf/
    – deps/
    – layout.cfg
    – others/
    – scripts/
    – setup.py

按照最初的设计，deps目录下会存放一些目标程序运行时依赖的库、工具等。但就一些细节并未考虑清楚，比如如果一个程序需要在两个平台（linux和solaris）上运行，那deps下的依赖库应该如何存放？

就这个问题一线的人员在设计setup工程时采用的策略是将某个库的所有平台版本都手工放到deps下，以instantclient这个oracle的客户端库来说，就形成了如下结构：

deps/
    – instantclient/
        – 10.2.0.5.0/
            – x86_64_linux/
                – lib/
            – x86_64_solaris/
                – lib/

这样一来安装包制作完后size非常的大，不便于存储和传输。另外手工copy依赖库显然不够专业。打包过程是buildc来完成的，而buildc是拥 有全部依赖库的存储位置、版本等信息的。于是我们就这个问题做了改进，让buildc 0.2.0支持将依赖的第三方库根据目标程序运行平台类别自动打包到最终的安装包中。

也就是说，如果你是为x86-64 linux平台做的安装包，最终安装包中的目录结构会是：

deps/
    – instantclient/
        – 10.2.0.5.0/
            – x86_64_linux/
                – lib/

而这一切仅需通过配置完成。在setup工程顶层目录的setup.cfg文件中，我们增加了一个新配置项，用于描述目标程序运行时依赖哪些第三方库，这些库将被打包到安装包中，并部署到目标主机上去。

配置的格式如下：

dependences = [
    ("instantclient", "10.2.0.5.0", ["libclntsh.so", "libclntsh.so.10.1", "libnnz10.so"]), # 打包指定的库文件
    #("instantclient", "10.2.0.5.0", []), # 打包instantclient/10.2.0.5.0下所有的库文件
    #("instantclient", "10.2.0.5.0"),     # 打包instantclient/10.2.0.5.0下所有的库文件
]

通过例子可以看出dependences中的元素支持三种形式配置，可以指定打包的库文件，也可以将库目录整体打包。

BTW，buildc自从发布以来一直没有user guide，好消息是项目组的小兄弟wtz1989227已经在wiki上建立了buildc_user_guide页面，后续他会逐步完善这个guide的。