2011年十二月月 发布的文章

2011·读过的书

2011年我的确读了不少书,掐指算来纸版和电子版加在一起近50本,其中以技术类居多,但其他方面的也有一些。这里列出来做个简单回顾。

一、技术类
· 《你必须知道的495个C语言问题
早在这本书出版前,其译者已经在网上完成了C FAQs的翻译(在这里)。这本书是基于最新C FAQs做了重新整理(包含C99)。虽说是最新,但因C语言近几年来变化很小,内容与之前译者在网上公开的那个免费版本相差不多。这本书适应面很广,初学者可以从中了解到很多谭氏教程中没有的东西;有经验的C程序员可以把它当成一本手册,需要时翻看。对于那些很在乎C语言细节的程序员来说,翻看一遍也未尝不可。

· 《The New C Standard – An Economic and Cultural Commentary
这本书的作者真是牛X的一塌糊涂。整本书居然是对C99规范的逐句解释,而且写成了一部1600多页的大砖头。这本书应该未正式出版,我看的是作者在网上放出的免费电子版。如果你痴迷于C语言规范的细节,这本书是一本不可多得的辅助资料。

· 《C和C++安全编码
Cert C/C++安全编码经验的浓缩版,读一遍的确可以提高一些编码过程中的安全意识。

· 《Practical Common Lisp
Peter Seibel编写的一本荣获Jolt大奖的Common Lisp入门书。你在这里可以看到这本书的免费电子版,其中文版名为《实用Common Lisp编程》,现在在我的书架上也躺着一本,我还没抽出时间来看。如果你是Common Lisp初学者,这本书是不二的首选。

· 《ANSI Common Lisp
Lisp语言的著名吹鼓手Paul Graham的大作,成书于Common Lisp标准化之际,是一本不错的Common Lisp入门的辅助资料。个人认为将《Practical Common Lisp》与此书结合在一起来学习,会加深你对Common Lisp的理解。

· 《Haskell – The Craft of Funcitonal Programming 2nd
这是一本比《Programming in Haskell》更适合作为函数式编程语言入门的书。书中第一章对函数式编程基本概念的讲解很是到位,并且这本书已经被译成了中文,书名为《Haskell函数程序设计艺术》,在网上可以免费下载到。

· 《Seven Languages in Seven Weeks
估计大家都见过《21天学会X语言》这样的编程语言教程。21天学会某种编程语言已经有些差强人意了,但这本书更狠 – 书名的直译是"七周学会七门语言",但显然本书的目标不是这样的。作者的原意是希望读者通过阅读本书了解更多的新兴编程语言以及编程范式,改变编程思维,另外通过本书的阅读可以初步掌握各种语言,并且对语言的掌握程度不仅仅是"Hello World"这一层次。今年年初与其他人合译了此书,也是在那时将这本书通读了一遍。我负责翻译Prolog、Scala和Haskell三个章节。在书中作者将每一门语言比作成一个电影中的人物,使得内容更加生动形象(但翻译起来就没那么容易了^_^)。特别值得一提的是:该书还荣获了今年的Jolt大奖,由此可见业界对该书的认可。

· 《Python参考手册(第四版)
像Python这样的动态编程语言,一直以极高的开发效率著称,这也是我今年学习和使用Python的一个原因,Python强大的标准库可以帮我快速实现一些想法(buildc就是用Python编写的)。《Python参考手册》这本书并不适合作语言入门之用,里面对语言细节的讲解很少,其内容更多适用于工程参考,包括库函数使用、打包、发布等,这正是当时我所需要的。

· 《持续集成》和《持续交付
持续集成已经是存在已久的一个最佳实践了。《持续集成》一书对这方面内容做了极其系统的讲解;持续交付将持续集成的概念做了进一步延伸,将软件开发的前段(设计、编码、单元测试)与后段(功能测试、压力测试、发布、部署、验收测试)衔接在一起,形成了一个整体,并通过自动化手段实现了这一概念。在我看来《持续交付》一书更像是一本cookbook,作者将自己实施持续交付过程中采用的方案以及遇到的问题都详实地记录在书中,分享给大家。这本书获得了今年的Jolt技术图书类最高奖,很是值得一读。

· 《深入理解计算机系统 2nd
本书的第一版是在大学毕业后不久读的,当时真有一种相见恨晚的感觉,读完后战斗力陡增。若干年后第二版的中文版终于出炉了,我又迫不及待地买下,并通读了一遍。这本书究竟咋样,从我豆瓣上给的评语可以看出:"如果只允许我为程序员们推荐一本书,那么我会毫不犹豫的将这本csapp推荐给大家。太经典了!"

· 《Binary Hacks》和《Debug Hacks
讨厌日本人,但有些时候你的确还得向日本人学习,这两本书都是由日本程序员执笔的,而且内容都是有关系统编程以及OS内核编程和调试的,内容比较深,需要你静下心来细心体会,国内程序员往往比较浮躁,愿意做底层技术的很少,坚持下来的就更少了,这方面日本程序员却是我们的典范。有关系统级编程和调试经验和技巧的资料在市面上比较少了,这也凸显了这两本书的价值。

· 《A Bug Hunter's Diary
这本书只是粗略的浏览了一些,书里的案例实在看不下去,总觉的Debug这事儿只有自己亲手去做才能有所得,就像看《盗墓笔记》一样,看完后你依旧不会倒斗,只有亲自倒一次斗才能学到真本事。

· 《Linux系统编程
知名Linux内核维护者Robert Love的作品,结合底层原理的机制讲解是本书一大特色,但总体比较平淡,有些地方更像是函数使用手册,建议有经验的程序员快速浏览一遍即可。

· 《Linux系统管理技术手册
简直就是一本Linux系统管理的大百科全书,内容涵盖各种主流Linux发行版,如RHEL、Debian、OpenSuse、Ubuntu等,极其适合放在抽屉里随时翻阅,我就是这么做的。

· 《Pragmatic Guide to Git》和《Pro Git
前者适合Git入门,后者适合Git进阶。一个版本控制工具,没有什么好说的。对于Git学习的建议是:要领悟Git背后的思想,另外不要将Git命令的含义与svn等传统版本控制工具的命令混淆,Git命令需全新认知。

· 《软件研发之道
典型的"新瓶装老酒",该书早在N年前就出过一中译版,名为《微软团队 – 成功秘诀》。如果你看过后者,你大可不必购买此书。不过如果你没看过这本书,那么还是建议看看,虽说书中讲的是微软当年Visual C++团队的事情,但读后你会发现其中的思想至今仍极具价值。

· 《编程之道
这是一本奇书,一本悬在空中的书,全书通读完后,你可能依然不知作者所云,但你的内心却已被作者的思想洗礼。

· 《编程匠艺
如果你认为《代码大全2nd》是好书,那么你也会喜欢这本书,它们是一类的。

· 《大话设计模式
这类书的目标都是意图将晦涩难懂的《Design Pattern》一书通俗化。但一般看这类书的时候,身旁还要放上一本《Design Pattern》,随时翻阅查证。今年在考量用C实现Pattern时顺便读完了这本书,总体来说算是国内讲解DP比较优秀的一本了。

· 《企业应用架构模式
Martin Fowler在2003年的作品,也是当年Jolt效率大奖获得者。当时也是企业应用架构蓬勃发展的时期 – J2EE大行其道,轻量级框架方兴未艾。作者将当时进行企业应用架构设计一些经验模式进行了详尽的总结并写成此书。在企业应用设计方面,我了解甚少,这也是今年阅读此书的一个主要原因。

· 《走出软件作坊
为数不多的国内IT企业技术管理者的经验之谈,很多人在书中会找到自己的影子。

· 《黑客与画家
Paul Graham的又一部大作,与之前的那本不同,这本更像是Paul的散文集,看完后是否能受益,全看你的悟性了。

· 《构建高性能Web站点
我不是搞Web开发的,但此书前三章对Web站点性能影响因素的分析还是让我受益匪浅的。

· 《程序设计语言原理
从China-pub淘来的一本特价书,但读了之后我感觉即使是原价买来也是很划算的。

· 《程序开发心理学
温伯格的经典之作。由于原著成书较早,经过几十年很多思想其实早已经通过其他渠道灌输到我们的大脑中了,但越是这样我们越是惊叹于温大牛惊人的预见力。要知道这本书最早成书于1971年。

· 《算法技术手册
今年读的唯一算法类书籍,这本书不像《算法导论》那样钻理论牛角尖,也不像《程序员实用算法》那样着重于算法的实现,它旨在赋予你精确选择算法的能力,以帮助你精确高效地解决面临的问题。

二、社科类
· 《
杰克.韦尔奇退休后的总结之作。记得上次陪LP参加桩考,我用了大半天时间在我的Bambook上把这本书浏览了一遍。不过在我这个层次上尚无法理解杰克全部之言。这本书对于不同层次的人会有不同的价值。它就是那种需要你在不同时期反复多次阅读的一本书。也许若干年后再读此书,我会有更深刻的认识。

· 《浪潮之巅
今年我读到的最震撼之作。之前吴军在Google黑板报上连载时我并未太过在意,这次系统地通读一遍后,让我眼界大开,从书中学到了许多,同时也激发我想到了许多。

· 《搞定: 无压工作的艺术》(Getting Things Done的中译版)和《时间管理:小强升职记
前者是GTD时间管理理论的源头,后者则是国内GTD牛人的经验之作。时间管理是今年我的一个重点改进目标,这两本书给了我很大帮助。

· 《哪来的天才
这本书向我们阐述了一个观点:刻意练习是天才的一个必要条件。如果你不认同,那么打开这本书,慢慢看吧。

· 《把时间当作朋友
原新东方英语教师李笑来的作品,很难想象他这样的职业能写出这种题材的书。

· 《重来
来自一个创业公司创业者们的颠覆性观点。

· 《少有人走的路
感觉没有外界宣传的那么好,也许我还没有悟到。

· 《卓有成效的管理者
管理学大师的作品总是值得一读的,虽然你很可能已经从其他场合学到过其中的思想。

三、传记类
· 《活着就为改变世界》和《史蒂夫·乔布斯传
看《活着就为改变世界》时,乔布斯还活着;后来乔布斯去逝了,我拿到了《史蒂夫·乔布斯传》。感谢京东的促销活动,让我以超低的价格买到乔帮主留给世人的这最后的礼物。两本书都告诉我一个事实:乔布斯的确与众不同,但讨厌他、憎恨他的人也大有人在。

· 《世界因你不同
以前看过李开复的《做最好的自己》,对李开复有些了解,所以读这本传记时也就走马观花了。

· 《留德十年》和《牛棚杂忆
一直很想知道季羡林为何被称为国学大师,通过回忆录是了解这个大师的一个很好的途径。

四、小说类

· 《盗墓笔记系列
这类题材的书籍总是吸引人的眼球,就如作者所说的“盗墓代表着人类一种最原始的欲望,求得财富和探询死亡,这种刺激,恐怕是人就无法避免的"。不能去倒斗,看看别人如何倒斗也能满足一些欲望^_^。

· 《三体
慕名而读,名不虚传。作者超凡的想象力让人不能不折服,至少第一部是如此。

· 《高地
今年看的唯一一部军旅题材小说,在部门旅游来回的途中把这部小说看完,情节跌宕,情感细腻,值得一看。

五、其他类
· 《准备去美国读书
为了了解美国教育是什么样子的,从图书馆借阅的,如果你和我有同样的目的,这本书还是可以满足需求的。

· 《实用IT英语
简直就是为IT人士量身定做的外语书,着重培养"英语思维"的形成,感觉书的内容也比较新颖。

很多朋友可能会问:工作这么忙,家庭生活琐事那么多,哪里还有什么时间读书呢?我又何尝不忙呢,每天8小时工作,周末还要陪果果。这里的关键还是要有坚定的读书信念,养成良好读书习惯,就好比一日三餐那样,非读不可。另外还要不断提高读书效率,充分利用零散的时间。现在市面上电纸书(比如kindle、bambook)越来越成熟,便携性也越来越好,你可以把坐车、等车以及闲暇休息这些零散时间充分利用起来,一年下来你挤出来的时间也是惊人的。

2011小结

2011年眼看就要接近尾声了,这里也对自己在2011年的"所作所为"做个小结^_^。

这一年来工作之外的我过得还是比较充实的,从下面的数字也可以看出:
- 写了81篇博文
- 开源了2个工具(CBehavebuildc)
- 合译了一本书("Seven Languages in Seven Weeks",不过尚未出版)
- 读了近50本书(通过豆瓣读书统计)
- 新学了一门语言 – Common Lisp
- 新用了一门语言 – Python

学无止境。我内心中追求的是"持续成长",让自己感觉每一天都有进步,哪怕仅是一点点,所以上面这些事情对我来说绝对是快乐的,有成就感的。

在工作方面,2011是"蓄势"和"布局"的一年。无论是在产品开发还是团队组织调整方面,我都按照我的思路进行了重新布局。这样一方面可以提携一些骨干,让他们可以在更重要的岗位上发挥出更大的能量;另一方面也可以大大减轻我个人身上的一些事务性工作,让自己可以轻装上阵,静下心来思考一些事情,踏实地去做一些对部门长远发展有价值的事情,比如在线代码同级评审知识库的建设、开发构建管理辅助工具、使用虚拟化技术改善开发测试效率、生产环境软件升级的自动化操作等。这些工作也反过来让我变得更加主动,更敢于去打破常规。

年初在个人工作计划中设定了多个目标,现在看来大部分已经做到。但感觉在"给予下属同事更多关于高效工作方法和提高解决问题能力上的指导“方面做的还很不足。另外感觉自己在"包容他人"这块的进步似乎依旧不大,甚至感觉自己的脾气愈发见长,眼睛里基本容不下沙子,看来性格秉性这东西要改起来还真难。

我一直告诫自己:代码还得写,千万不能让自己手冷。这方面上半年做的还不错,下半年写的有些少,这几天感觉手有些痒痒了,特想写上个三天三夜。

2011的家庭生活总体来说是"平淡中蕴含着幸福",特别是每次下班进门时果果迎上来抱住我的大腿的时候,幸福的感觉尤甚。

既然是小结,那就写这么多了,都是捞干的了。至于来年的计划、目标以及愿望就留到来年再说道吧。

C语言项目构建管理辅助工具 – buildc

这几年我一直从事C语言项目的开发。这些项目的规模都不算小,少则十几万代码,多则几十万行代码,至少也都算得上是中型项目吧。项目构建工具使用的是传统的Make工具,构建脚本都是自行编写的,构建时直接在顶层目录下敲入make即可。

这种传统的构建方式其实是很耗时费力的。比如执行make之前你需要根据项目代码的实际路径重新设定一些环境变量或修改Makefile中的某些标识路径的变量;你还要将项目依赖的各种内部公共库、第三方开源库悉数找到,并安装在指定目录下,修改Makefile中这些第三方库的路径配置。只有做完这些后,你才能顺利地执行Make。以后每当你更换一个环境,你就要将上面的步骤重复执行一遍。有的项目第三方依赖较多,要完整地搭建一个项目构建环境所耗费的时间也是很惊人的,特别是对一些不熟悉项目构建的新人更是如此。另外随着产品被要求具备在多个平台上运行的能力,你的构建脚本还要支持在多个平台上的构建,你要为项目所依赖的第三方库准备多个平台的版本;当某个依赖库版本进行了升级,你还要手工在多个环境下进行更新。

为了使项目构建更加容易,我们曾经对Makefile脚本进行了改进,比如自动判断和设定当前顶层路径、自动判定当前项目代码所在的平台,并根据不同平台设定不同的变量值;甚至将项目依赖的第三方库放入subversion服务器,构建项目时通过Shell脚本自动checkout对应平台的依赖库并链接。这些改进都是有效的,但在修改了多个项目后,我们发现了坏味道,那就是在不同项目的Makefile中充斥着大量重复性的脚本代码,这让后续构建脚本的维护十分困难,在一个项目中修正了构建脚本的bug后,很容易遗忘另外几个项目中存在着同样bug。此外每次构建都重新下载项目依赖的第三方库会导致构建变的十分缓慢。

我们在构建中遇到的问题大致就是这么多了。估计很多人会问:你们为何不用autotools生成的configure来生成项目构建脚本?为何不用scons等更加高级的构建工具呢?我的回答是即使使用了这些工具依旧无法解决现有的所有问题。比如利用configure->make可以屏蔽掉一些平台移植的问题,但依旧无法解决第三方库依赖的问题。scons我也试用过,但了解不甚深入,我的印象中它的主要功用是简化构建脚本的编写,让大家从Makefile那纷繁复杂的源文件依赖关系中解脱出来,至于在区别平台以及解决第三方库依赖方面估计也无能为力;另外还有一个原因那就是让大家从已经十分熟悉的构建模式中转到scons的成本也是不小的。

我们的问题其实并非构建脚本的编写问题,而是构建环境的管理问题。autotools和scons所解决的问题属于前者,即构建脚本的编写问题。而解决C语言项目构建环境管理的工具我了解的不多,在互联网上也没有google到。在这方面Java项目倒是有一个很好的工具 – Maven。利用Maven可以做很多事情,我对其了解不多,这里也不多说,但这里提到Maven是因为它的一个Feature启发了我,这个Feature就是对第三方依赖包的管理。虽说C项目依赖的第三方开源包也越来越多,但与Java项目相比那还是小屋见大屋。实际情况是一个Java项目如果不依赖十几个或几十个第三方开源包都不好意思拿出去说。这样一来如果手工找齐这数目庞大的开源包会让Java程序员头痛不已。Maven的这个Feature恰好帮助Java程序员解决了这个难题。Maven可以根据配置自动从互联网上下载指定版本的依赖包,后续Java项目的构建可直接使用已经下载到本地的包;Maven似乎还会定期自动更新第三方包的版本。

受到Maven这个特性的启发,我于是就开发了这款C语言项目构建管理辅助工具 – buildc(项目主页http://code.google.com/p/buildc)。buildc工具本身是用Python语言实现的,这主要是考虑到Python较高的开发效率以及自带功能强大的标准库。这也是我第一次用Python写程序,个人认为buildc的代码十分混乱,内部实现耦合较高,扩展性差,也谈不上什么风格,都是命令式语言的思维,代码本身并没什么价值,以后有时间定会重构^_^。

buildc目前主要实现了两个功能:
1、第三方依赖库的远程获取和本地管理
2、根据目标主机环境、目标主机本地缓存的第三方库情况以及项目本身所依赖的第三方库的最新配置,自动生成一份包含了依赖库环境变量信息的Make.rules文件,或重新更新已有Make.rules文件(上一次由buildc生成的)。项目中的Makefile只需包含(include)Make.rules文件并使用该文件中的变量即可。

buildc的使用是有前提条件的,那就是第三方库必须按特定规划集中存储在一个版本控制服务器中,buildc目前仅支持Subversion。我不是很清楚Maven是如何从互联网上获取对应第三方开源包的jar包的,但我们很难直接获得C第三方库的二进制版本。这里面主要有两点原因:
1、C语言的第三方包多以源码包的形式提供;
2、Java号称"一次编写,到处运行",也就是说Java第三方库仅需提供一份jar包即可运行在多个平台上;但C的二进制库不能,每种平台都会有对应的特定的版本,我们无法将一种二进制库应用到多个平台上。

因此我们首先需要构建组织内部的第三方库集中存储服务器,将各个产品需要的第三方库在各个平台上进行构建,并将得到的静态库或动态库放入版本服务器中。符合buildc要求的二进制库的组织形式如下。比如在svn://127.0.0.1:6666/3rds这个repository下面我们的第三方库按如下组织形式存放:

3rds/
      – libevent/
            – 2.0.10/
                – README
                – source_code_package
                – sparc_32_solaris/
                     – include/
                     – lib/
                – sparc_64_solaris/
                – x86_32_solaris/
                – x86_64_solaris/
                – x86_32_linux/
                – x86_64_linux/
      – netsnmp/
            – 5.2.0/
                …
            – 5.7.0/
                …
      … …

可以看到每个第三方库的组织形式都像下面这样:
package_name/
    – version/
        – CPU_MODE_OS
            – include
            – lib

一旦第三方库都按如此形式存储,buildc就可以获取到该服务器上的二进制库了。前提满足后,我们就来看看buildc在日常构建过程中的使用方法。

一、buildc的安装
buildc目前尚未做成python安装包,只是以源码形式提供的。所以现有情况下只需Checkout或下载buildc源码包到本地即可以使用。

buildc的源码目录结构如下:

buildc*        # 脚本入口
build_utils/   # 源码库
templates/     # Make.rules.in模板
samples/       # 配置样例

为了方便在任意路径下使用buildc,可将存放buildc源码的目录加入到PATH环境变量中去。另外你可能还需执行'chmod u+x buildc'来为buildc加上执行权限。

二、环境初始化
执行buildc init,buildc会在你的HOME目录下建立.buildc.rc文件。该文件用于配置所有可用的第三方库的信息。

$> buildc init
Copy /home/tonybai/proj/build_tools/samples/buildc.rc.sample to /home/tonybai/.buildc.rc OK!
Please config /home/tonybai/.buildc.rc before you use other buildc commands!
Copy /home/tonybai/proj/build_tools/samples/buildc.cfg.sample to ./buildc.cfg OK!
Please config buildc.cfg before you use other buildc commands!

# $HOME/.buildc.rc
foo_repository = ('svn://10.10.0.156:6666/foo',
                       '~/.buildc_libs/foo',
                       [
                        ('snmp', '5.7.0', 'lib/libnetsnmp.a'),
                        ('libexpat', '2.0.1', 'lib/libexpat.a'),
                        ('libiconv', '1.13.1', 'lib/libiconv.a'),
                        ('libevent', '2.0.10', 'lib/libevent.a'),
                        ('lcut', '0.2.0', 'lib/liblcut.a'),
                        ('instantclient', '10.2.0.5.0', 'lib/libnnz10.so')
                       ]
                      )

bar_repository = ('svn://10.10.0.156:6667/bar',
                         '~/.buildc_libs/bar',
                         []
                 )

external_repositories = [
                          foo_repository,
                          bar_repository
                        ]

其中foo_repository和bar_repository分别代表两个可用的集中存储第三方库的服务器,每个repository中的详细配置包括svn repository的url、这个repository的本地缓存路径以及构建所需的该repository中的第三方库信息。

buildc init还会提供一个buildc.cfg配置文件,该配置文件在后面再细说。

三、第三方库的本地缓存管理
有了正确的.build.rc配置,我们就可以初始化第三方库在本地的缓存了,执行buildc cache init。

$> buildc cache init

===>Begin init repository [svn://10.10.0.156:6666/foo]
Create dir: /home/tonybai/.buildc_libs/foo
library [snmp] does not exist!
Checkout [svn://10.10.0.156:6666/foo/snmp/5.7.0/x86_64_linux]…
Checkout [svn://10.10.0.156:6666/foo/snmp/5.7.0/x86_64_linux] OK!
library [libexpat] does not exist!
Checkout [svn://10.10.0.156:6666/foo/libexpat/2.0.1/x86_64_linux]…
Checkout [svn://10.10.0.156:6666/foo/libexpat/2.0.1/x86_64_linux] OK!
… …

buildc cache init命令会根据.buildc.rc中的配置,从各个repository中下载对应该主机平台的第三方库,存放在对应的缓存路径下备用。

如果repository有更新,我们可以执行buildc cache update来更新本地缓存(在实际的日常开发过程中你可以将该命令加入到crontab中来定期自动更新本地缓存):
$ buildc cache update

===>Begin update repository [svn://10.10.125.156:3560/3rds]
Update [snmp]…
Update [snmp] OK!
Update [libexpat]…
Update [libexpat] OK!
… …

当不需要本地缓存时,我们可以通过buildc cache remove删除之:
$> buildc cache remove

===>Begin remove repository [svn://10.10.0.156:6666/foo]
Remove [/home/tonybai/.buildc_libs/foo] OK!
<=== End remove repository [svn://10.10.0.156:6666/foo]
… …

四、生成项目Make.rules
第三方库的本地缓存建立好后,我们就可以来配置项目了。在前面执行完buildc init时,buildc生成了一个项目配置模板文件buildc.cfg(.buildc.rc和buildc.cfg本身也都是Python源文件),我们将该文件移到项目的顶层目录下,然后对该文件进行配置,下面是一个例子:

#(proj_name, (major, minor, revision), author)
project = ('foo', (1, 3, 1), 'tonybai')

# [(libname, libversion, [archives*])*]
external_libs = [
 ("snmp"  , "5.7.0", ["libnetsnmpagent.a", "libnetsnmphelpers.a", "libnetsnmpmibs.a", "libnetsnmp.a"]),
 ("libexpat" , "2.0.1", ["libexpat.a"])
]

# [def*]
# e.g. ['-Dprint_msg=printf', '-D_SELF_DEBUG_']
custom_defs = [
                '-Dprint_msg=printf',
                '-Derr_msg=printf'
              ]

# [(var, value)*]
# e.g. [ ('WITHOUT_DB_IMPORT', 'TRUE'), ('SUPPORT_MYSQL', 'TRUE') ]
custom_vars = [
                ('WITHOUT_IMPORT', 'TRUE'),
                ('WITHOUT_NM', 'TRUE')
              ]

# [include_path*]
# e.g. ['./include', '/home/tonybai/.include']
custom_includes = [
                    './include'
                  ]

# [(lib_path, [archives])*]
# e.g. [('/home/tonybai/.lib', ['libfoo.a', 'libbar.so']), (‘.libs’, ['libzoo.a'])]
custom_libs = [
                ('.libs', ['libfoo.a']),
                ('', ['libzoo.so'])
              ]

这里简要说明一下这个配置文件的各个配置项:
* external_libs是项目所使用的第三方库列表,这些第三方库必须存在于该主机的本地缓存中,也就是.buildc.rc中拥有这些库的配置;
* custom_defs是项目需要额外传递给编译器的命令选项集合;
* custom_vars是你想额外在Make.rules定义的变量集合;
* custom_includes是额外需要单独指定的的头文件包含路径集合;
* custom_libs是项目所需额外的(不在本地第三方库中存储的)库路径,比如一些系统库。

完成buildc.cfg的配置,我们就可以通过buildc config-make来生成Make.rules文件:
$ buildc config-make
Can not found Make.rules in current directory!
Generate [/home/tonybai/proj/foo/Make.rules] …
Config [/home/tonybai/proj/foo/Make.rules]…
Config [/home/tonybai/proj/foo/Make.rules] OK!
Generate [/home/tonybai/proj/foo/Make.rules] OK!

生成的Make.rules如下:
#
# Make.rules for foo
#
# tonybai
# 2011-12-08
#
# @Generated by buildc@
#

# Project information
TOPDIR = /home/tonybai/proj/foo#@topdir@

# Platform information
OS = linux#@os@
CPU = x86#@cpu@
CMODE = 64-bit#@cmode@

# Version information, (MAJOR.MINOR.REVISION)
MAJOR = 1#@major@
MINOR = 3#@minor@
REVISION = 1#@revision@
VERSION = $(MAJOR).$(MINOR).$(REVISION)

# Compiler options
DEFS = -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_DEBUG_ -DVERSION=\"${VERSION}\"
… …
CUSTOM_DEFS = -Dprint_msg=printf -Derr_msg=printf #@custom_defs@
CC = gcc -m64#@cc@
CFLAGS = $(FDEBUG) $(FWALL) $(FPIC) $(FOPTIMIZE) $(DEFS) $(CUSTOM_DEFS) $(INCLUDES)

# Library infomation
snmp_ROOT = ~/.buildc_libs/foo/snmp/5.7.0/x86_64_linux#@lib_roots@
libexpat_ROOT = ~/.buildc_libs/foo/libexpat/2.0.1/x86_64_linux#@lib_roots_end@

LIB_INCLUDES = -I $(snmp_ROOT)/include -I $(libexpat_ROOT)/include #@lib_includes@
LIBS_DEPEND =  -L $(snmp_ROOT)/lib -lnetsnmpagent -lnetsnmphelpers -lnetsnmpmibs -lnetsnmp -L $(libexpat_ROOT)/lib -lexpat#@ libs_depend@
CUSTOM_LIBS = -L .libs -lfoo -lzoo#@custom_libs@

# Headers
DEFAULT_INCLUDES = #@default_includes@
CUSTOM_INCLUDES = -I ./include #@custom_includes@
INCLUDES = -I $(TOPDIR)/include $(LIB_INCLUDES) $(CUSTOM_INCLUDES) $(DEFAULT_INCLUDES)

# Libraries
DEFAULT_LIBS = #@default_libs@
LIBS = $(LIBS_DEPEND) $(CUSTOM_LIBS) $(DEFAULT_LIBS)

# Other definitions
WITHOUT_IMPORT = TRUE#@custom_vars@
WITHOUT_NM = TRUE#@custom_vars_end@
… …

你可以对比着项目buildc.cfg的配置来查看Make.rules的构成。如果bulidc.cfg配置发生变化,那么再次执行buildc config-make会更新当前路径下的Make.rules。Make.rules的生成和更新使用了基于模板的标记替换技术。

五、利用Make.rules构建项目
可以看出Make.rules中将平台信息和第三方库的依赖信息都放置在对应的变量中了。项目的Makefile只需要包含Make.rules便可以利用这些信息进行项目的构建。可以利用的Make.rules中的主要变量包括:CFLAGS、LIBS。我们甚至可以为项目再编写一个"一键构建"脚本,该脚本中只需包含两行代码即可:

buildc config-make
make

你无需将Make.rules提交到源码版本库中,但需要将buildc.cfg作为项目的一部分。这样在任一一个通过buildc做项目构建管理的环境中,你的项目就都可以进行"一键式"构建了,再也无需为配置项目路径和寻找构建第三方依赖库而发愁了。另外通过buildc进行构建管理的项目将会很容易地集成到持续集成过程中。

buildc与make的组合模式很类似于maven和ant的组合,但buildc目前的功能还无法与maven相比,不过buildc也不打算做成maven的模样。buildc后续可能会支持从更多种版本管理服务器(比如git)下载第三方库,支持按指定模板生成Make.rules(目前只有一种模板)等特性。从目前实践的情况来看,buildc这个项目构建管理辅助工具十分适合我们内部的C项目构建,也许它也同样适合你的项目,有兴趣的朋友不妨试试。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多