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下的依赖库应该如何存放？ ...
近期看到一则新闻，说是Microsoft推出了一门开源的编程语言叫TypeScript，该Project的主要负责人是大名鼎鼎的Anders Hejlsberg，就是那个Turbo Pascal 、Delphi以及C#之父。结合近几年来出现的颇受关注的其他几门编程语言，如Go、Rust、Dart等，让我感觉到编程语言似乎进入了"拼爹"时代。 我们来列举一下这几门新兴语言的“老爹”(设计者)： * Go语言 – Robert Griesemer、Rob Pike和Ken Thompson。 这里最著名也最NB的当属Ken Thompson，Unix之父，并与Dennis Ritchie一起创造了最伟大的工业编程语言C，图灵奖得主。Rob Pike也是Bell Labs元老，Unix和Plan 9计划的参与者，Limbo语言的设计者之一。至于Robert Griesemer名气似乎小一些，我也不甚熟悉。不过有了前两位，想必Golang就会有足够的号召力了。 ...
Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It’s a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. – 摘自Go语言官方站点 ...
随着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，上述问题就得到了解决(如果你的单元测试真实需要链接动态共享库，那就另当别论了)。 ...