Buildc

很多人学习和使用Golang一段时间后，都会被golang的第三方包依赖版本搞得有些烦躁，golang设计者最初过于乐观的设计使得今天大 家不得不各自想办法解决这个问题。godep就是综合了多年第三方包依赖问题的解决方案后的一个趋向统一的方案，至少是在go get的设计没有进化前的一个比较不错的方案。 今天试用了一把godep，不过“体验”并不理想，这缘于我遇到了godep的一个“坑”，不过是那种你在正式项目中不一定遇到的“坑”，这里来说到说到。 ...

随着buildc在内部应用的深入，buildc逐渐进入了以内部需求和问题为主要驱动力的演化模式。我们内部的C应用多是后端服务类应用，个人 觉得具有一定代表性。buildc最初就是为了针对这类C应用而设计的。因此我们内部的需求和问题应该也同样具有一定代表性，而这种演化模式在一 段时间范围内还是有意义的。 buildc 0.3.1版本修正了上一版本的若干bug，并增加了两个新功能。 * 提高容错能力 ...

自buildc正式在项目中应用以来，我们收到了许多同事针对buildc演进的意见和建议。其中确实有些易用性的问题是在最初设计时未考虑周全的，尤其是.buildc.rc中的配置，同事们对该文件的配置已经“怨声载道”了。 .buildc.rc是用来配置某开发者在开发过程中使用的第三方库所在subversion repository信息的，例如： a_repository = (‘SVN库地址’, ‘本地缓存路径’, [ # 格式：[(“第三方库名称”, “库版本”, “特征库文件”), …] (’libevent’, ‘2.0.10’, ’lib/libevent.a’), (‘instantclient’, ‘10.2.0.5.0’, ’lib/libnnz10.so’), … ] ) b_repository = (‘SVN库地址’, ‘本地缓存路径’, []) c_repository = (‘SVN库地址’, ‘本地缓存路径’, []) … external_repositories = [ a_repository, b_repository, c_repository, … ] ...

眼看2013年已经过去1/6了，这个谋划显然有些晚了。之所以晚，根本原因还是之前有些很多事情没有想清楚，即便是现在可能依旧比较朦胧。鉴于去年的目标执行情况不甚理想，尤其是工作目标方面，因此今年在谋划策略方面变得更加务实和收敛，期望能说到做到或做的尽可能的多。 ...

2012年有一个目标我没有达成，那就是深入学习和使用Python语言。这个目标被其他学习任务和工作无情的抢占了，当然最主要的原因还是我重视不够^_^。 近期恰逢有一些Python工程的开发工作要做，就顺便略微深入地学习了一下Python：看了几本Python的英文大部头，比如《Learning Python 4th Edition》、《Python Essential Reference 4th Edition》、《Programming Python 4th Edition》、《Expert Python Programming》以及《The Python standard library by example》，看得我有些要吐了^_^。虽然之前用Python开发过buildc，但自我感觉依旧还是一个Python的绝对beginner，这 次通过这几本书的学习算是对Python有了个较为系统的了解了。 ...

随着buildc在项目中的深入使用，开发和测试人员都提出了不少良好意见，让我们有些应接不暇了，这次的版本更新也是为了满足这些意见和建议。 由于忙于应对这些眼前的需求，原本0.3.0的改进计划也被推迟了一些。 buildc 0.2.2版本包含了两个主要修正。 * 增加了–ignore-error命令行选项 ...

buildc 0.2.1版本是一个bugfix版本，修正了两个重要问题。 * 修正执行buildc pack –cmode=32-bit时无法创建32位安装包的问题 之前的buildc pack命令在打包安装程序时忽略了–cmode这个选项，这样即便传入32-bit这个参数，打出的安装包中的应用程序依旧是64位编译的。这次修正了这个问题，让buildc真正支持打32位程序的安装包。 ...

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目录下的几个文件，这里的文件多为因工程的不同而异的。 ...