随着buildc在项目中的深入使用，开发和测试人员都提出了不少良好意见，让我们有些应接不暇了，这次的版本更新也是为了满足这些意见和建议。 由于忙于应对这些眼前的需求，原本0.3.0的改进计划也被推迟了一些。

buildc 0.2.2版本包含了两个主要修正。

* 增加了–ignore-error命令行选项

自从buildc cache相关命令严格区分–cmode=32-bit还是64-bit后，用户在使用过程中出现了一些新情况。比如某开发人员A负责两个子系统 subsys1和subsys2的开发，这两个子系统分别用到了lib1和lib2。subsys1是一个64bit系统，依赖lib1；而 subsys2是一个32bit系统。依赖lib2。这样开发人员A在自己的开发环境下要管理和缓存lib1和lib2。管理lib1时，用到的 是buildc cache update –cmode=64-bit命令，而管理lib2时，用到的是buildc cache update –cmode=32-bit命令。这时如果内部的二进制库服务器上没有lib1的32bit版本或者没有lib2的64bit版本，buildc cache相关命令就会执行失败。为了临时解决这个问题，我们增加了–ignore-error命令行选项，这样即便lib1无32bit版本 或者lib2无64bit版本，buildc cache相关命令执行不会失败，开发人员A开发环境下的subsys1和subsys2的构建也会顺利完成。

关于这个问题，后续期待在buildc 0.3.0版本或后续版本得到更好的解决。

* 增加buildc pack source –component=[src|deps|all]命令

通常情况下，我们是不需要在生产环境下做任何编译操作的。但有些特殊情况下，我们不得不将源码拿到生产环境下进行编译。之前使用buildc进行 源码构建的工程拿到生产环境下进行编译极为不便，因为生产环境下没有buildc环境，也没有依赖库的cache，因此我们的运维人员提出这样的 需求：提供一份可在生产环境下进行编译的source包。为了满足这一需求，我们针对setup工程进行了完善，对buildc的pack命令做 了扩充，使得buildc pack支持source打包。

buildc pack source支持三个component参数：src、deps和all。src意为源码包，包中只包含工程源码；deps是打依赖包，及包中包含的都是 工程依赖的对应平台的第三方库的二进制版本；all则是src和deps的合体，是一个全量的，在目标环境可直接编译的包。

buildc pack source输出的目标包内结构大致如下：

target-package/
    – deps/
        – lib1/
            – 1.1.0/
                – x86_64_linux/
    – proj_name
        – configure
        – Make.rules
        – Makefile
        – ….

前面说过，这个包在目标环境是直接可编译的，你只需执行：
$>./configure
$> make

在制作目标包时，buildc pack source命令就已经将Make.rules中的各种库的依赖信息按照目标包的结构做了调整。执行configure是为了根据目标环境对 Make.rules做最后的调整。

另外源码包仅携带对应目标平台的第三方库的版本，不会将所有平台的版本都带上。当然这样有利有弊。优点在于源码包的size不会很大；缺点在于， 如果生产环境有许多种平台的话，我们需要为每个平台准备一份源码包。

BTW，现在的buildc基本上由我们组的小兄弟wtz1989227一个人维护，包括buildc的manual更新，这次的更新也都是他一 个人的工作成果。小声的说一句：wtz1989227接触Python也为时不多，因此代码方面还有较大的改进提高余地。 

职场上的朋友可能经历过以下两种截然不同的状态：

（一）
每天早晨起来都有一种强烈要上班工作的冲动；
一到公司，立即感觉精力充沛，并希望尽快开始做事，不能浪费一分一秒；
每天下班前回顾一天的工作时，都能感觉到收获和进步，并带着笑容下班；
每天回到家里，暂时忘记工作，与家人共度良霄，养足精力；
生活与工作保持一定距离，这始终让你与工作之间有美的感觉。

（二）
每天早晨一想到要上班，就愁云遮面，总想在床上多睡一会，拖延上班时间；
一到公司，就精神萎靡，思维闭塞，浑浑噩噩；
每天下班前回顾一天的工作时，毫无感觉，只是感觉忙乱中时间就流逝了；
回到家里，却仍被工作压力驱使，埋头伏案，远离家人；
生活和工作如稀泥一样搅和在一起，工作让你感到恐惧。

千万不要觉得以上内容是我杜撰出来的，这是真切发生在你我身边的事实。同样是在工作，状态却为何能有如此天壤之别呢？不同的人给出的答案也许不同，而这里我要说工作幸福感使然：前者显然是工作幸福感富足的结果；而后者则是缺乏工作幸福感在作祟。

俗话说“乐也一天，烦也一天”，每个人都希望自己每天都能快乐的活着。如果你目前正处于第二种状态或者说有向第二种状态转移的迹象，那是时候考虑如何调整一下自己了。恰逢新年伊始，这里我来说说如何提升工作幸福感，做一个善于驾驭工作的人，而不是被工作牵着鼻子走的人。

以下观点来自本人亲身体会，不一定完全正确，仅供参考和讨论。

* 选择可以产生幸福感的工作

世上没有绝对地无法产生幸福感的工作，但对于大多数平常人来说，一些种类的工作的确无法带来幸福感，比如富士康生产线上的零件组装工种，实难想像在那种岗 位上如何产生幸福感，因此跳楼事件频发也就不足为奇了。我无法枚举出所有可以产生幸福感的工作种类，但至少程序员这份工作还是具备产生幸福感的属性的。虽 然我们中国程序员总是习惯自嘲地称自己为“码农”，可“码农”也有收获的幸福时刻啊。程序员这份工作还是需要有创造性的，主观因素对结果的影响比例还是蛮 大的；编码也被认为是一种匠艺，这说明其中有一定艺术的成分。有艺术，就会有美丑的评判。追求和收获美的代码是会让人感觉到幸福的。不过这个世界是现实和 残酷的，为了生存而选择了那些幸福感无几的工作是十分普遍的，当然这种社会问题不是本文所能解决的了的。

* 做自己愿意做的事情

在中国，公务员这种工作想必大家都会认为会产生幸福感。传统印象中，公务员是广义的“官”的现代叫法，而老百姓大脑中的“官”的形象无非是坐在办公室里抽 烟、喝茶、看报纸，这确是一份旱涝保收的工作，但坐在办公室无聊地度此一生是否是你真正愿意去做的事情呢？这只是一个生动的例子罢了，我要说明的是即便是 从事着可以产生幸福感的工作，也不见得就会有工作幸福感，还要看这个事情是否是你真的愿意去做的，是否真的是你感兴趣去做的，是否是真正全心投入去做的。 微观上来看，即便从事了愿意去做的工作，但涉及到具体的事情，也会有好恶之分。以程序员这个职业为例，也分为不同角色，你是愿意做Coding还是愿意做 tech manager；你是愿意做产品还是愿意做项目？时刻记住只有做自己愿意做的事情，幸福感才能眷顾到你。Steve Jobs的一句话教育了我们：“跟随你的内心”。

* 明确的工作目标

很多人在工作当中时常感觉空虚和迷茫，这显然会降低工作幸福感。反思一下这种感觉究竟来自什么？就我个人的体会来说，每当工作目标不明确时，我就会有这类 感觉。反之，明确的目标犹如大海上的灯塔，为你指明前进的方向；让你有的放矢；让你的付出充满了确定性，让你对预期更加有信心，它会让你的心中由衷产生一 种愉悦。

* 工作成果有及时反馈

就如小学生第二天看到作业本上老师的评语那样，我们也希望能尽快看到工作成果的反馈：正面的反馈给人以鼓舞；负面的反馈给人以警醒。反之，零反馈则让人气馁，失去了继续的动力，自然没有幸福感可言。

* 挑战带来幸福感的波峰

在职场中，每天的情形不同，收获不同，体味到的工作幸福感的强弱就有不同。俗话说：有付出就有收获。付出的越多，一旦收获，得到的也就越多。因此只有那些有挑战的，值得让你付出更多的工作才能带来巨大的成就感，从而催生出幸福感的波峰。

* 帮助他人解决工作中的问题

“予人玫瑰，手有余香”，积极地帮助他人解决工作中的问题，会让你的工作幸福感油然而生。让你的工作幸福感弥漫在工作的环境当中，让这种氛围感染熏陶更多的人，以营造一个幸福的工作氛围，提升团队的整体工作幸福感。

* 与志同道合的人一起工作

看看你周围的同事，是否和你是一路人。“道不同不相为谋”，别花时间和心思在那些和你不对路的人的身上了，年纪也不小了，脑细胞也是有限的，吐沫星子也不 是白来的。那些通过一个眼神、一个手势就能知你意的人才是你真正的工作伙伴，和他们一起工作才能有幸福感。能选就选，能避就避吧。

* 定期回顾，潜意识中进行自我肯定

无论是否得到了上级或同事的反馈，定期的工作回顾和总结对保持工作幸福感总是大有裨益的，尤其是回顾过程在潜意识中的自我肯定会很大程度上提升你的工作幸福感。

* 与幸福生活相互映衬

中国人讲：“家和万事兴”。工作之外我们是离不开家庭生活的。我们要学会平衡，把握生活与工作的间距，学会让两者之间互相保持美感。幸福的工作下映衬的是幸福的生活，反之，在幸福生活的的映照下，工作幸福感也会显得更加强烈。工作和生活是相辅相成。

演喜剧的，不见得他每天的生活都是喜剧。最近感觉工作幸福感有所流失，这直接促使了我进行了如上的反思。新年伊始，我也在自我调整中。