自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,
                        …
                   ]

这里面需要维护最多、最频繁的就是各个repository中具备的第三方库名、版本号。开发者所开发的项目所依赖的第三方库信息发生变化，不仅仅需要修 改project下的buildc.cfg文件，还可能要修改.buildc.rc，大家维护起来确实体验不好，会多耗费一些工作量。

针对这个主要问题，我们决定对buildc进行一次较大范围的重构，重构后的版本定为buildc 0.3.0版本。以下是buildc 0.3.0版本的主要改动点：

一、简化.buildc.rc的配置，重新定义cache相关命令的语义

0.3.0及以后版本的.buildc.rc只需配置repository的地址信息以及cache缓存的本地路径信息，无需再提供repository 里面具体的第三方库以及版本号信息了，这样一来，大多数情况下，project依赖的第三方库发生变更，都无需修改.buildc.rc了。

a_repository = ('SVN库地址', '本地缓存路径')
b_repository = ('SVN库地址', '本地缓存路径')
c_repository = ('SVN库地址', '本地缓存路径')
…
external_repositories = [
                        a_repository,
                        b_repository,
                        c_repository,
                        …
                   ]

随之而变的是buildc cache相关命令的语义，0.3.0中cache相关命令的语义如下：

* buildc cache init - 生成.buildc.repository，该文件是svn库的目录结构文件，相当于一份svn repository内部的地图，repository中存放的各种第三方库以及版本均在该文件中索引；如果该文件已经存在，命令执行的结果为：提示已存在。

* buildc cache upgrade – 根据.buildc.rc的最新更新，重新生成.buildc.repository文件，并将该文件中所有lib本地的 Revision号置为none。该文件并不会执行本地cache的library的真实更新操作。

* buildc cache update  - 
    1. 如果.buildc.rc已经修改，但没有执行buildc cache upgrade，update会对比本地缓存库信息与对应的.repository文件中的同名lib信息，如果不一致，则提醒执行upgrade。
    2. 如果.buildc.repository是新生成的，所有lib本地的Revision号均是none，则提示没有要更新的本地缓存库；
    3. 如果某个项目已经download了自己依赖的库，那update将比对svn库中和本地库的revision差异，并下载最新库版本。并修改.buildc.repository中对应库的本地revision number。

* buildc cache remove – 将.buildc.repository中对应库的本地revision number都置为none，并删除本地缓存的库文件。

二、重新定义config make的语义

前面提到了，在执行buildc cache init时，buildc只是负责生成.repository文件，而并不真实执行库文件的下载和缓存。那何时真正下载呢？答案是在执行buildc config make时。这里颇有些“lazy evaluate”的味道，需要时再“download and cache it"。

* buildc config make

1. 如果.buildc.rc已经修改，但没有执行buildc cache upgrade，config make会对比本地缓存库信息与对应的.repository文件中的同名lib信息，如果不一致，则提醒执行upgrade。
2. 如果.buildc.rc是新生成的，或执行cache upgrade后的，config make会根据project对应的buildc.cfg中配置的第三方库，在.buildc.repository中查找是否存在（包括对应的版本 号），如果存在，则从subversion server端自动下载；否则提示出错。
3. 如果本地缓存中某个库文件不存在，buildc config make会检测到，并自动下载该库，并cache起来。
4. 如果subversion端某个库的svn revision号发生的更新，buildc config make会检测到，并下载最新的版本。

总之一切都是在buildc config make时来完成的，按需下载或更新，这样你甚至无需进行手工的library Cache维护。

三、转向OO范型

实现buildc 0.3.0的小同事(wtz1989227@gmail.com)对OO情有独钟，因此在这个版本中，他将以前的结构化代码做了大幅度调整，并用OO的方 式进行了重构。按照wtz的思路，这次改造比较初级，OOD做得还不够充分，以后慢慢调整。实际代码中反映出来的情况也的确是这样。

四、buildc 0.2.3发布

在将buildc 0.3.0代码merge到trunk之前，我创建了buildc-0.2的maintain branch，虽然理论上buildc 0.3.0在功能和配置方面与buildc 0.2.x版本是兼容的，但毕竟代码调整幅度较大。另外建议大家都转移到0.3.0这个最新版本上来，buildc-0.2分支顶多做一些bugfix， 不会再有新feature添加进去了。

昨天在发布buildc 0.3.0的同时，还发布了buildc-0.2的一个Bugfix版 – buildc 0.2.3，该版本主要做了如下一些fix：

  * 执行cache upgrade时增加对.buildc.rc中repository特征文件存在性的检查；
  * 执行config make时增加对Make.rules文件是否为空的判断；
  * 执行pack source时，添加VERSION文件，记录打包的上下文信息。

五、其它

考虑到github的活跃度远远高于google code，加上google code最近访问十分不稳定，因此之前就将buildc（还有cbehave、lcut以及我的实验代码库）fork了一份到github上了，也攒攒 github上人气，因此这次buildc 0.2.3和buildc 0.3.0的代码还要发布到github上一次。git工具平时用的少，尤其是提交代码到github，这次算入门了。

* 代码远程提交
用git remote add一个github的remote repository后，就可以使用git push origin master将本地的commit推送到github上了。

* 打tag，并推送tag

   — 查看Tag的git命令是git tag；
   — 本地打tag，用这个命令： git tag -a v0.2.3 -m"0.2.3 released"；
   — 推送Tag到remote repository：git push –tags origin master，不加–tags是无法推送tag的。

* branch操作
  — 查看branch：git branch
  — 创建branch：git branch buildc-0.2
  — 推送branch：git push origin buildc-0.2
  — 本地切换branch：git checkout buildc-0.2

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

一、个人目标

* 鉴于去年的执行情况，今年将blog定在80篇（大约每5天一篇）应该问题不大，毕竟blog已经成为我生活的一个重要组成部分了。

* 阅读是必不可少的。今年计划将读书目标定在40本（大约每9天一本）。去年的读书效率下降许多，感觉更多是因为自己变得懒散了。所以今年除了“扫库存”之外，还增加了一个改善措施：从省图书馆借书读。俗话说：书非借而不能读也^_^。借书读，一方面降低书架上的书增长的速度，减少了开支；另一方面还可能提高读书效率，借的书毕竟是要还的么^_^。昨天在整理果果的书时发现我的书架已经接近满员了，所以以后非经典书/非紧急书就不打算买了，不知道能否借此戒掉“买书瘾”，想必到时侯还是会纠结一番的^_^。最后在读书方面还是要给自己设置一条主线的，尽量围绕自己的目标达成去选择读哪些而不读哪些，读自己所需要的，按照自己的思路去读，千万不要人读己亦读。

* 学习新编程语言方面。每年一门新语言，但今年目标不甚明确。对函数式语言有些担心，前途似乎没有看起来的那么美，可预见到情况是将长期持续在小众领域徘徊。今年的策略是看缘份了^_^。在日常工作中，Python这门语言的使用是愈来愈多了，今年在Python方面肯定是要继续深入研究一点点的。

* 开源方面。我将继续和同事一起推进buildc的演进，至少会完成已经策划已久的0.3.0版本的设计与实现。在开源方面目前尚未参与过其他人发起的项目，这块更多还是自己找点子，期望今年能有一些新的想法。

* 个人健康方面。前些日子得了肺部感染，连续挂了近两周点滴才控制住病情，钱没少花，罪没少遭，还好目前看起来像是痊愈了。恰因为此，今年才把这个单独拿出来作为个人目标的一部分。事后分析，之所以被细菌感染，更多是因为自己的免疫力太低了。事实上也是这样的：去年一整年都没有什么锻炼身体的活动，免疫力不低就怪了。所以今年打算把晨跑提上日程，记得11年是晨跑坚持时间最长的一年，每天跑上3km，各方面的感觉的确是非常好的。

* 关注代码。和2012相比，今年期望能抽出更多的时间和精力编写自己的代码、阅读和评审其他人的代码。对于程序员出身的我而言，代码的魔力是我无论如何都无法抗拒的。

* 其他能力提升方面。今年重点想提升一下当众Speaking能力。目前当众讲话是没啥问题的，但如何当众把话讲的更好更具吸引力，这方面还需要专门的学习和训练。

二、工作目标

不得不承认去年工作方面的失意让我对工作的热情有所衰退，所以今年在工作目标方面尽量收敛一些，也不想在这里把一些具体目标展开说明了，唯一所求的就是踏踏实实把重点任务做好。另外任何事情做久了，都想期待有一些变化。

三、家庭目标

虽然去年的家庭目标完成的十分不错，不过有了去年的家庭目标做铺垫，今年的目标达成难度加大了许多，压力山大啊。这里先列出一些简单的：

* 更新数码装备：本本、手机、相机、平板、电纸书等。
* 给果果转到规模较大的幼儿园，接受更为规范的教育。
* 常回父母家看看。
* 家庭成员省内、国内、境外游至少各一次。
…. 这里省略很多更难实现的家庭目标。

与工作相比，感觉我在家庭生活上的掌控力更弱一些，让我纠结的事情也更多一些。至于原因么，男人都懂的。

总体来说，至少从这篇blog的篇幅上来看，2013的目标比2012年要收敛许多，尤其在工作方面。有些事情等做完了再说也未尝不好。