安装包

一切没有目标的努力，都是瞎忙活儿。 - Tony Bai 刚实施回来，就又投入到新工作中，到今天才有那么一点点时间写写这件事儿。 * 缘起 我们的遗留系统性能一直不高，导致这一局面的因素有很多，比如最初设计和实现的“考虑不足”、后续维护人员的“随波逐流”甚至缺少勇气对影响性能的关 键代码进行重构等等。技术债务就这样一直积累着。直到两年前，我们终见其导致的巨大的影响了。 ...

buildc的演进先后经历了构建管理和安装包工程管理两个阶段。其中buildc的构建管理功能在项目中应用较早，目前相对稳定可靠。但其支持的安装包工程是直到最近才被大家所正式使用的。不出意料，大家在使用过程发现了一些问题，于是我们也是边用边改。 目前一个setup工程一般具有类似如下源码组织结构： distributions/ setup.cfg src/ – README – app/ – conf/ – deps/ – layout.cfg – others/ – scripts/ – setup.py 按照最初的设计，deps目录下会存放一些目标程序运行时依赖的库、工具等。但就一些细节并未考虑清楚，比如如果一个程序需要在两个平台（linux和solaris）上运行，那deps下的依赖库应该如何存放？ ...

随着buildc使用的深入，越来越多的新需求暴露了出来。为了满足这些需求，我们组的小兄弟又对buildc进行了一些改造，这些变化如下： 1、支持将多个子工程打包到一个安装包中 最初buildc的设计思想是为每个子工程单独制作安装包，这样具有很强的灵活性。但在对现有N个工程进行构建脚本改造的过程中发现，有些工程间存在严重 依赖，比如工程A是一个业务级公共库工程，工程B和工程C都依赖工程A构建后生成的静态共享库。而工程A又无法被当成第三方库处理，这给我们的安装包构建 制造了难题。我们的解决方法就是改造安装包工程的setup.cfg文件，让其支持多source。从正规语义上来讲，我们这么做将使得buildc支持 将多个子工程打包到一个安装包中，而间接的作用则是解决了上述有依赖关系的工程安装包制作的问题，虽然看起来不那么美。 ...

buildc这个小工具逐渐在项目组内部扩大了使用范围，还有一名专门的同事负责为每个项目制作安装包工程，这样也可以在使用中发现buildc的问题。 本次buildc 0.1.8的相关修正以及新增的feature就是我的这位年轻同事一手操刀完成的，他也是一个python新手，同样也是边翻手册边进行编码的。这次改动主要集中在templates目录下的几个文件，这里的文件多为因工程的不同而异的。 ...

最近针对buildc又有了一些新想法，于是今天上午又对buildc进行了多处修改，并相继发布了0.1.6版本和0.1.7版本。 * 对buildc cache upgrade的实现进行了修改。 在执行全量更新本地cache前，先对本地cache的情况进行一些检查，并判断是否与当前.buildc.rc中的配置相符。如果两者是一致的，那么只进行update操作；否则则执行真正的upgrade(remove and re-init)。 ...

这两天对buildc的改动比较频繁，今天又修正了一些问题，也增加了一些小功能。主要包括这么几点： 1、在Make.rules.in中增加了STATIC_LIBS和DYNAMIC_LIBS 项目源代码和项目中单元测试代码使用同一个Make.rules，也此编译时也就共享同一个LIBS变量。对于静态共享库还好说，但对于动态共享库，诸如Oracle的instantclient库，单元测试代码中即使没有使用到动态共享库中的接口，也要对该动态共享库产生一个依赖。这样在执行单元测试用例时就会因无法寻得动态共享库而导致用例执行失败。 为此，我在Make.rules.in中增加了STATIC_LIBS和DYNAMIC_LIBS两个变量，即将原LIBS变量中的静态共享库和动态共享库分开，分别放入STATIC_LIBS和DYNAMIC_LIBS中。然后让项目中单元测试代码的编译只依赖STATIC_LIBS，上述问题就得到了解决(如果你的单元测试真实需要链接动态共享库，那就另当别论了)。 ...

年后buildc开始逐渐在产品线的项目里应用了，随之而来的是大家反馈的各种意见和bug。尤其是bug，我都会很认真地应对，也会及时发布相应的版本修复这些bug。buildc 0.1.4版本就是一个bugfix版本，其修复的bug源于今天上午的一次持续集成的失败。 上午收到Jenkins发送的一个"build failed"的mail，一个安装包项目的CI job执行失败了，于是到Jenkins web页面上检查错误原因。这个Job会在两个slave node上执行集成，一个在x86 linux上，一个在x86 solaris上。这次失败是因为x86 linux上的一个配置问题导致的，页面显示x86 solaris那个节点的集成是成功的。我无意间查看了x86 solaris节点集成过程的命令行输出，发现如下内容： ...

在"也谈C应用安装包制作与部署“一文中，我提到了为每一个源码工程建立单独的安装包制作工程(setup project)的想法，这两天我就一直在折腾这件事儿^_^。 最初我并没有想去搞一个通用的安装包制作工具，只是为一个现有的源码工程建立了一个试验性质的安装包工程，并实现了其构建脚本(build.py)。但之后考虑到各个项目都要建立一个对应的安装包工程，安装包工程的构建脚本build.py势必会沦落成被copy来copy去的下场，这显然不是一个很好的解决问题的办法。那是否需要再单独设计和实现一个安装包制作工具呢？工具多了，大家用起来肯定会很烦，不能自找没趣^_^。要知道为程序员编写工具可是一件很困难、很头疼，需要你很谨慎的事情。现在我们已经有了源码工程构建工具buildc，我前几天还为buildc添加了安装脚本，并用之改造了一个真实的工程，并给大家做了讲解，可以说大家对buildc算是接受了。 ...

虽然部门一直在做C应用，但这么多年来，在C应用的安装包制作以及部署方面做得还是很初级，可以说还没有达到规范的程度。各个产品线的C应用安装包种类多样，水平参差不齐：有些产品的源码包即是安装包，把源码包拿到生产环境下编译后使用；有的项目则将编译好的目标文件(.o)以及第三方库放在安装包中，在生产环境下重新链接生成可执行文件；有的组则稍微专业一些，安装包中放的是编译好的可执行文件，但在目标主机上安装和执行时也都遇到了一些问题，诸如运行环境中的第三方库版本号与程序所依赖的不一致等。 去年年底，我就将"C应用安装包制作和部署"的改进作为今年的一个工作重点。这两天我粗略地考量了一下这方面的内容，这里也简单地谈谈。 ...