这两天对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语言编码规范进行一些修订。为了"有米下锅"，我还特意在网上找了一些相关资料。关于C语言编码风格和标准的资料大多都成稿于上个世纪90年代，也就是在C90发布之后的若干年里；在C99发布后，部分资料根据最新的规范做了修订，但也有些资料认为C99对整体风格影响不大，也就保持了原样。 在这些资料中，我重点关注了一下这份文档《Recommended C Style and Coding Standards》，它是著名的"Indian Hill C Style and Coding Standards"的更新版，从Google的搜索结果来看，似乎影响很广。这份文档内容不多，言简意赅，特别是后面的几个小节，例如宏、条件编译、可移植性以及ANSI C等章节很值得细致阅读和理解。 ...
今天着实是一个值得纪念的日子，因为我终于完成了从BlogBus到WordPress的搬家工作，从此我的Blog将站在一个新的起点上。 自从2004年开博以来，我坚持了七年多，至今仍孜孜不倦，写博客已经成为我的生活中不可或缺的一部分，即使在微博等大行其道的今天，我亦然如此。作出搬家的决定显然是十分痛苦的，因为要抛弃已经建立起来的使用习惯以及Blog人气(包括搜索引擎索引、外部引用的等)是十分艰难的。但我还是决定搬家，更多是因为我的一个小小的梦想：拥有一个自己可以完全控制的独立域名的个人站点。 tonybai.com这个顶级域名是在2010年申请的，2010年末曾经尝试过一次搬家，但因技术原因最终没能实现。但鉴于BlogBus提供的服务愈发地不稳定，我又动了搬家的念头，而且有了上次失败的教训，这次我做好了充足的资料和技术准备。但即使如此，搬家过程依旧很辛苦，并且足足花了我一周多的业余时间，下面就来罗嗦一下搬家的过程。 ...
在"也谈C应用安装包制作与部署“一文中，我提到了为每一个源码工程建立单独的安装包制作工程(setup project)的想法，这两天我就一直在折腾这件事儿^_^。 最初我并没有想去搞一个通用的安装包制作工具，只是为一个现有的源码工程建立了一个试验性质的安装包工程，并实现了其构建脚本(build.py)。但之后考虑到各个项目都要建立一个对应的安装包工程，安装包工程的构建脚本build.py势必会沦落成被copy来copy去的下场，这显然不是一个很好的解决问题的办法。那是否需要再单独设计和实现一个安装包制作工具呢？工具多了，大家用起来肯定会很烦，不能自找没趣^_^。要知道为程序员编写工具可是一件很困难、很头疼，需要你很谨慎的事情。现在我们已经有了源码工程构建工具buildc，我前几天还为buildc添加了安装脚本，并用之改造了一个真实的工程，并给大家做了讲解，可以说大家对buildc算是接受了。 ...
buildc在发布0.1.0版时并没有做好安装脚本，当时的建议是直接下载0.1.0的源码包或svn export/checkout源码包，并手工将buildc目录位置加入到用户的PATH环境变量中。近期buildc计划正式投入到项目中使用，为了方便大家安装以及以后的统一升级维护，我花了些时间给buildc加上了setup脚本。 Python有标准的程序分发方案，不过我对这些了解不多。buildc本身很简单，我觉得没有必要把安装做得很复杂，所以就自己动手编写了一个setup.py，不到100行，用于安装buildc。 Python的标准安装脚本也叫setup.py，我这里也借鉴了这个名字。有了setup.py，buildc的安装就简单多了： * 下载buildc Release包(当前最新是buildc-0.1.1) * 解压发布包，在发布包路径下，执行setup.py install [–prefix=YOUR_INSTALL_PATH] ...
这几年我一直从事C语言项目的开发。这些项目的规模都不算小，少则十几万代码，多则几十万行代码，至少也都算得上是中型项目吧。项目构建工具使用的是传统的Make工具，构建脚本都是自行编写的，构建时直接在顶层目录下敲入make即可。 这种传统的构建方式其实是很耗时费力的。比如执行make之前你需要根据项目代码的实际路径重新设定一些环境变量或修改Makefile中的某些标识路径的变量；你还要将项目依赖的各种内部公共库、第三方开源库悉数找到，并安装在指定目录下，修改Makefile中这些第三方库的路径配置。只有做完这些后，你才能顺利地执行Make。以后每当你更换一个环境，你就要将上面的步骤重复执行一遍。有的项目第三方依赖较多，要完整地搭建一个项目构建环境所耗费的时间也是很惊人的，特别是对一些不熟悉项目构建的新人更是如此。另外随着产品被要求具备在多个平台上运行的能力，你的构建脚本还要支持在多个平台上的构建，你要为项目所依赖的第三方库准备多个平台的版本；当某个依赖库版本进行了升级，你还要手工在多个环境下进行更新。 ...
“A language that doesn’t affect the way you think about programming， is not worth knowing”. — Alan Perlis(ACM 第一任主席，图灵奖得主，1922-1990) 《程序员修炼之道》这本书建议程序员每年应至少学习一门新的语言，以拓宽思维，避免墨守成规。今年我选择了函数式编程语言Haskell。选择Haskell的理由正如Alan Perlis所说的那样，Haskell是一门可以影响程序员编程思维的语言，我也期望通过学习Haskell来拓宽我的思维。 ...
近期中国移动推广3G业务普惠大众，推出多款3G定制机参加存话费增手机活动。先是一位同事存了一款多普达的强机，这让我心痒不已^_^。但是Windows Mobile的系统我是不喜欢的。到辽宁移动网站上查看了一下参加活动的机型，发现了一款心仪的型号：摩托罗拉MT710，就是近期电视广告里频频曝光的那款黑红机，上周六我就迫不及待的到营业厅将这款强机请回了家。 ...
近两天一有空就会去看看项目代码，思考一下如何利用cmockery对项目里已有的代码进行测试。项目代码中很多被调用的接口都带有输出参数，而且在这些接口中多利用返回值指示执行成败也否，而利用输出参数返回一些关键结果，这些结果值甚至影响着后续的函数执行流程。前期研究cmockery时没有注意到cmockery是否可以设置被mock接口的输出参数的值，不过回顾了一下cmockery实现的原理，觉得cmockery是应该可以支持的。遂重新翻看了一下cmockery的manual，发现在mock_query_database中确有对输出参数的mock调用，代码如下： // Mock query database function. unsigned int mock_query_database( DatabaseConnection* const connection, const char * const query_string, void *** const results) { *results = (void**)mock(); return (unsigned int)mock(); } void test_get_customer_id_by_name(void **state) { DatabaseConnection connection = { “somedatabase.somewhere.com”, 12345678, mock_query_database }; int customer_ids = 543; will_return(mock_query_database, &customer_ids); will_return(mock_query_database, 1); assert_int_equal(get_customer_id_by_name(&connection, “john doe”), 543); } ...