buildc的演进先后经历了构建管理和安装包工程管理两个阶段。其中buildc的构建管理功能在项目中应用较早，目前相对稳定可靠。但其支持的安装包工程是直到最近才被大家所正式使用的。不出意料，大家在使用过程发现了一些问题，于是我们也是边用边改。

目前一个setup工程一般具有类似如下源码组织结构：

distributions/
setup.cfg
src/
    – README
    – app/
    – conf/
    – deps/
    – layout.cfg
    – others/
    – scripts/
    – setup.py

按照最初的设计，deps目录下会存放一些目标程序运行时依赖的库、工具等。但就一些细节并未考虑清楚，比如如果一个程序需要在两个平台（linux和solaris）上运行，那deps下的依赖库应该如何存放？

就这个问题一线的人员在设计setup工程时采用的策略是将某个库的所有平台版本都手工放到deps下，以instantclient这个oracle的客户端库来说，就形成了如下结构：

deps/
    – instantclient/
        – 10.2.0.5.0/
            – x86_64_linux/
                – lib/
            – x86_64_solaris/
                – lib/

这样一来安装包制作完后size非常的大，不便于存储和传输。另外手工copy依赖库显然不够专业。打包过程是buildc来完成的，而buildc是拥 有全部依赖库的存储位置、版本等信息的。于是我们就这个问题做了改进，让buildc 0.2.0支持将依赖的第三方库根据目标程序运行平台类别自动打包到最终的安装包中。

也就是说，如果你是为x86-64 linux平台做的安装包，最终安装包中的目录结构会是：

deps/
    – instantclient/
        – 10.2.0.5.0/
            – x86_64_linux/
                – lib/

而这一切仅需通过配置完成。在setup工程顶层目录的setup.cfg文件中，我们增加了一个新配置项，用于描述目标程序运行时依赖哪些第三方库，这些库将被打包到安装包中，并部署到目标主机上去。

配置的格式如下：

dependences = [
    ("instantclient", "10.2.0.5.0", ["libclntsh.so", "libclntsh.so.10.1", "libnnz10.so"]), # 打包指定的库文件
    #("instantclient", "10.2.0.5.0", []), # 打包instantclient/10.2.0.5.0下所有的库文件
    #("instantclient", "10.2.0.5.0"),     # 打包instantclient/10.2.0.5.0下所有的库文件
]

通过例子可以看出dependences中的元素支持三种形式配置，可以指定打包的库文件，也可以将库目录整体打包。

BTW，buildc自从发布以来一直没有user guide，好消息是项目组的小兄弟wtz1989227已经在wiki上建立了buildc_user_guide页面，后续他会逐步完善这个guide的。

时间真是过得飞快，遥想一年前的这个时候我们在产品线的知识管理试水有了一点成绩，便在组织内力推知识管理。领导经过权衡后，也认同了知识管理的重要性， 并随即安排人在组织内部快速建立起了知识库。在最初的一两个月里，临时的知识管理负责人热情很高，做得还算不错，初步地将知识库是什么、如何使用以及组织 知识管理的第一版规范和大家交待清楚了。但随着热情的消逝，知识库管理也随波逐流了，知识管理开始变得名存实亡，这种状态持续了大半年。

领导层的原因我这里不去分析。领导自然有生存问题要考虑。知识管理这等重要但不紧急的事情，还是留给我们去考虑吧。知识管理没有预想中的那样在组织内形成 工作风气，究其原因还是缺少持续的运营。大家知道即便是再好的事物如果缺少了持续经营和关注，也会逐渐消亡的。试想如果新浪微博没有持续的宣传投入哪会有 今天这种地位。

上周和几位组织内的资深同事一同讨论了知识管理的现状，不能再这样下去了，我们要在民间做点工作。由于都不是专业搞知识管理的，所以把我们讨论出来的策略暂且称为“野路子”^_^。我这里也将我们产品线兼职做知识管理的MM“贡献”给组织，协助做组织知识管理的经营工作。

以下是初步确定的几点经营策略：

1、团队经营

之前只是有一个临时知识负责人，除了职责范围不明确外，一个人“单打独斗”也确实心有余而力不足。因此知识管理的经营必须要有一个团队，可以是实体专门团 队，也可以是虚拟团队。团队必须有专门的负责人，专职也好，兼职也罢，有胜于无。团队应该按照做项目或做产品的方式去对待知识管理，有计划、有目标、有阶 段步骤的去经营；另外团队内部人员有分工，有些负责策划、有些负责技术、有些负责推广等，总之团队经营是一个组织搞好知识管理的必要条件。

2、借鉴和效仿

我们不是专业的知识管理团队，但业界却有好多已经做得很成功的知识管理策略值得我们借鉴和效仿，比如智库(MBAlib)等。另外一些知名SNS服务的提供商的经营策略也是值得我们学习的，即便知识管理与通常的SNS有很大不同。

以下列举一些参考策略：

- 培养达人(名人)，影响长尾。新浪从其博客开始一直就是这么做的，后期微博更是复制这一策略，腾讯微博也是照搬效仿。在组织内部，培养分享和总结知识的达 人，树立他们在知识库贡献中的领袖地位。并在这一过程中，通过宣传和引导，逐渐让更多人了解知识库，效仿达人们形成总结和分享知识的良好工作习惯。

- 持续让大家被动关注。通过各种手段让大家持续感受到知识管理在组织内的存在，比如定期全员发送知识简报、组织知识管理达人秀活动、白板宣传等方式。 

- 持续改善页面体验。一个易用和好用，可以快速上手的知识库是让大家积极参与到知识管理中的一个前提条件。因此作为知识管理重要环节的知识库，我们务必做到对其使用体验的持续改善。通过各种技术手段，让大家易访问、易编辑、易归类、易检索等等。

3、引入竞争机制，激发荣誉感

在知识管理过程中引入竞争机制。就像新浪微博勋章系统一样，为知识达人们分级，让大家产生知识分享的荣誉感。另外如果组织内部由多个子部门组成（就像我所在的组织那样），还可在子部门间引入竞争机制，这块具体采用何种机制就要看具体情况而定了，比如通过排名，或也给部门授予类似勋章的机制。

4、善用行政手段

知识的来源有随机自发的，也有规定必须的。因此有些知识整理和分享是在组织行政规定之下必须要做的，这部分内容也不能忽略，这可以让知识库内容更加丰满。另外还可以从长远考虑，将子部门对组织知识库的贡献纳入到子部门的业绩当中去。这手段有些别扭但可能真的有效。