码迷,mamicode.com
首页 > 编程语言 > 详细

Blade - 腾讯开源的构建系统 c/c++编译环境

时间:2015-12-16 12:38:14      阅读:6004      评论:0      收藏:0      [点我收藏+]

标签:

typhoon-blade

Blade is an advanced building system developed with python, majorly for C/C++

Blade 是一个现代构建系统,期望的目标是强大而好用,把程序员从构建的繁琐中解放出来。

Blade主要定位于linux下的大型C++项目,密切配合研发流程,比如单元测试,持续集成,覆盖率统计等。但像unix下的文本过滤程序一样,保持相对的独立性,可以单独运行。目前重点支持i386/x86_64 Linux,未来可以考虑支持其他的类unix系统。

在腾讯公司“台风”云计算平台开发过程中,为了解决 GNU Make,Autotools 的难用和繁琐的问题,我们开发了这个全新的构建系统,整个系统基于多个声明式的构建脚本,在构建脚本里,只需要声明要构建什么目标,目标的源代码,以及其直接依赖的其他目标,不需要说明如何构建。大大降低了使用难度,提高了开发效率。

首先,Blade解决了依赖问题。 当你在构建某些目标时,头文件有变化,会自动重新构建。 最方便的是,Blade也能追踪库文件的依赖关系。比如 库 foo 依赖库 common,那么在库 foo 的 BUILD 文件中列入依赖:

  1. cc_library(
  2.     name = ‘foo‘,
  3.     srcs = ...
  4.     deps = ‘:common‘
  5. )
复制代码
那么对于使用foo的程序,如果没有直接用到common,那么久只需要列出foo,并不需要列出common。

  1. cc_binary(
  2.     name = ‘my_app‘,
  3.     srcs = ...
  4.     deps = ‘:foo‘
  5. )
复制代码
这样当你的库实现发生变化,增加或者减少库时,并不需要通知库的用户一起改动,Blade自动维护这层间接的依赖关系。当构建my_app时,也会自动检查foo和common是否也需要更新。

说道易用性,除了依赖关系的自动维护,Blade还可以做到,只要一行命令,就能把整个目录树的编译连接单元测试就可以全部搞定。例如:

递归构建和测试common目录下所有的目标
  1. $ blade test common...
复制代码
以32位模式构建和测试
  1. $ blade test -m32 common...
复制代码
以调试模式构建和测试
  1. $ blade test -pdebug common...
复制代码
显然,你可以组合这些标志
  1. $ blade test -m32 -pdebug common...
复制代码
特点

          自动分析头文件依赖关系,构建受影响的代码。
          增量编译和链接,只构建因变更受影响而需要构建的。
          自动计算库的间接依赖,库的作者只需要写出直接依赖,构建时自动检查所依赖的库是否需要重新构建。
          在任意代码树的任意子目录下都能构建。
          支持一次递归构建多个目录下的所有目标,也支持只构建任意的特定的目标。
          无论构建什么目标,这些目标所依赖的目标也会被自动连坐更新。
          内置 debug/release 两种构建类型。
          彩色高亮构建过程中的错误信息。
          支持 ccache
          支持 distcc
          支持基于构建多平台目标
          支持构建时选择编译器(不同版本的gcc,clang等)
          支持编译 protobuf,lex, yacc, swig
          支持自定义规则
          支持测试,在命令行跑多个测试
          支持并行测试(多个测试进程并发运行)
          支持增量测试(无需重新运行的测试程序自动跳过)
          集成 gperftools,自动检测测试程序的内存泄露
          构建脚本 vim 语法高亮
          svn 式的子命令命令行接口。
          支持 bash 命令行补全
          用 Python 编写,无需编译,直接安装使用。

彻底避免以下问题:


    头文件更新,受影响的模块没有重新构建。
    被依赖的库需要更新,而构建时没有被更新,比如某子目录依赖遥远的某外部目录的代码,我在这个目录构建,外部目录的代码会被自动检查是否也需要重新构建。

致谢
Blade 是受 Google 官方博客发表的这篇文章的思想的启发而开发的: 云构建:构建系统是如何工作的

现阶段 Blade 生成 SCons 脚本进行构建,因此 Blade 的运行还需要依赖 SCons。

Python 是一种简单易用而又强大的语言,我们喜欢 Python。

Google 开放的一些库强大而好用,我们很喜欢,我们把对这些库的支持集成进了Blade中,既方便了库的使用,又增强了 Blade,这些库包括 protobuf,gtest, gproftools。

更多文档请参考 Wiki。

欢迎使用以及帮助我们改进Blade,我们期待你的贡献。

GAE 地址:http://code.google.com/p/typhoon-blade/

GitHub 地址:https://github.com/chen3feng/typhoon-blade




刀是什么样的刀?

诸位看到标题,千万不要以为我是模仿《锋利的JQuery》,或者什么书籍,而是因为,介绍Blade的文章,标题不得不这样。

Blade由腾讯台风云计算平台出品,大约在2012年下半年开源,它是一把专用于构建软件的宝刀。Blade的字面意义应该是"刀锋",意思是使用该软件构建软件更加强大,更加便捷。该系列宝刀,最早应该是由Google这位顶级刀匠打造而成,当年事迹见诸互联网记载:

http://google-engtools.blogspot.hk/2011/08/build-in-cloud-how-build-system-works.html

http://mike-bland.com/2012/10/01/tools.html#tools-blaze-forge-srcfs-objfs

 

听说Google内部打磨的宝刀,其名为"火焰刀",英文名为"Blaze",一样是锋芒毕露,炙热灼物,其面世后,以其熊熊烈焰,统一了google内部的软件编译方式。腾讯出品的blade, 英文写法,只有一字之差,不过"火焰""刀锋"各得风流,虽说取名有点像偶像致敬的意思,但是也是锋芒不让。

 

提起google的宝刀,其实到google洗练过几年武学的IT牛人们,在远走他方后,也都各自打磨了一把。我的前东家,就成绩打磨过一把类似的宝剑,取名"Ymake",名字是虽然朴拙了一些,但是假如你见过他们亮出过宝刀,也会被其锋芒所吸引。在云壤的江湖朋友们,都称道其"活儿好"。

 

就互联网上能搜索到的铸刀秘诀而言,我能搜索到的,应该是我的前任授业恩师放出去的,其实他应该还没有加入云壤。项目地址为:

https://code.google.com/p/qa52/

其BUILD语法,虽然还没有简洁到极致,但是功能上似乎看起来也已经有模有样。

 

其示例的BUILD文件如下所示:

技术分享

假如你仔细瞅瞅,会发现语法已经基本接近google开放出来的BUILD文件示例。

 

好吧,花了九牛二虎之力,追溯了blade的历史掌故,却还没点到题上。言归正传,blade其实是一个多语言的构建工具,之所以使用"构建",而不是"编译"两字,实在是因为软件构建并不仅仅是软件编译,而非我喜欢故弄玄虚。Blade除了编译软件以外,还奉上了很多其它的福利,比如集成了单元测试,性能测试等。这正如一把好刀,不仅应该能杀人,还且最好能力最短的时间内杀死对方,刀光一起,人已倒地,但是刀不流血,刀已回鞘。

 

那么,Blade藏身何处,不急,以下就是它的所在:

https://code.google.com/p/typhoon-blade/

https://github.com/chen3feng/typhoon-blade

目前该项目与陈峰维护,其微博名为"陈三丰",虽然我猜测可能是由于"陈峰"这个名字已经被他人抢先使用,继而只好采用拆字法,将"峰"一分为二,是为"三丰",不过从名字看,倒也和大侠张三丰很有渊源,就此而言,blade(刀锋)由他维护倒是最妙不过了。

刀锋的锋芒在哪里?

 

既然号称刀锋,那么其锋芒何在?为什么有了make这把天下闻名的好刀,还要试试blade的锋芒?

那么下面就在历数一下blade的不同凡响处。

天下武功,唯快不破

 

江湖上最知名的刀,无不以快而闻名,blade的一个好处,也是其编译速度快,快得益于几个方面:

1,可以进行并行编译和并行测试,

2,使用了ccache等库,可以将编译中间结果进行缓存。

3,如果使用了distcc模式,则可以享有更多的用于编译的硬件资源。听说google内部的blaze有三个模式,一个是Local,一个是distcc,一个是Forge,按理说,forge模式由于运行在大规模的集群中,编译的速度应该最为快。

刀虽为刀,却不仅仅是刀

 

在仙剑奇侠传四中,宝剑望舒,被男主角云天河各种虐待,从猎野猪、烤肉、劈柴到射箭、御剑,无所不用其极。而一把好刀,其功能自然不应该局限与杀人见血。

Blade作为一个构建工具,其作用不仅仅是替代makemakefile,且听我细细道来:

1Blade是软件工程的利器,有助于模块化,模块化的力度控制自如,对于提高系统的可维护性,复杂性的隔离,代码复用的最大化,都有很大的好处。

2Blade提供了单元测试的最佳使用方式。

假若单元测试和代码是分离的,编译代码和运行测试各自为政,那么往往测试只是测试,很难对开发有什么帮助,因为很多时候,虽然有测试代码,但是测试却很少被运行,或者时过境迁后,测试多有失效。大家假如编译过一些开源项目的话,可能就会有类似的经验,编译完静态库,拿到静态库文件就完了,很少有人去运行所有的单元测试,确保所有的测试都能运行通过。

有了Blade,通过cc_testgtest_main.a默认链接,使得单元测试的代码简化到极致。同时,主要运行blade test target,就能在编译完目标程序后,运行(而且可并发运行)相应的单元测试,以随时跟进代码是否已经偏离了该有的轨道,开发是否早已脱缰狂奔。

只要发布部署时,使用上Blade test target, 那么就可以保证,上线的模块,能够通过所有单元测试用例的验证把关。Blade集成单元测试,提供cc_test,看似功能简单,但是正是这个简单的功能,使得测试驱动开发,开发者测试等理念,能够在google全功能范围内得到认同并贯彻实现。

3blade实现了递归编译。

Blade build …即可对当前目录及其子目录下的所有编译对象进行编译。该功能虽然小,但是却很实用。在一个十几人的团队中,百万行级别的代码规模,只有递归编译功能,可以很方便地实现一个循环编译工具,当某个模块编译失败,或者某个单元测试失败后,自动发出邮件通知相关的开发人员,以保证频繁的开发提交代码成为开发。当然,相关的功能,可以通过类似hudson之类的软件完成。不过blade 递归编译,对中小规模的代码而言,基本已经游刃有余。

4blade 实现了依赖查询。

Blade query可以查询依赖到某个模块的所有模块,这个对于代码重构而言,是个不错的功能。假如你在重构code base,或者是修改接口,或者是fix bug,或者是改进性能,

都可能使得使用到该库的相关模块,集体罢工,单元测试无法通过。这时候,假如使用上blade query,你就可能编译相关模块,使得你提交的代码,不会给其它模块带来麻烦。

5blade绑定了静态代码审查功能。

对整个项目而言,严把质量关非常重要,因为一旦一些烂代码进去了,清扫牛粪的工作将会非常痛苦而且艰巨。这里的异己分子,可能包括bug,风格差异迥异等。

Blade 会在进行编译之前,会所有被变更的编码,使用指定的静态代码审查功能进行代码审查。C++代码审查脚本,google cpplint较为知名,地址为:

http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py

当然,每个公司都可以定制其自己的检查脚本,以符合其自己的代码风格等。

Blade绑定该功能,可以避免出现一些常见的Bug,统一团队的代码风格,对公司工程文化的塑造有润物细无声之效。

6,blade是编译的统一入口,并且是开放的

这点是最重要的,也是blade的锋芒所在。因为Blade是统一的编译如果,因此修改统一的编译选项,设置统一的编译警告级别,实现cc_test等全部成为可能。

只要愿意,你不仅可以在编译前实现代码审查,也可以在编译时设置不同的参数,选择指定的编译器,更可以在编译后,运行单元测试,统计单元测试覆盖率,当可以定制各种操作。

因为统一,所以要升级编译器,使用统一的警告级别等牵一发而动全身的动作成为可能。因为开发,实现cc_test, cc_benchmark, proto_library, thrift_library成为可能。

 

好使的刀,方为好刀

假如刀虽然,但是太笨重,使用起来仿佛破解机关,这只有寂寞的高手才能使用了,普通人得知,如同废铁。因此,好使的刀,才是好刀。

Blade之所以好使,在于其采用了足够简洁的语法,比如下面便是编译一个静态库libencoding.a的语法描述:

cc_library(

    name = ‘encoding‘,

    srcs = [

        ‘ascii.cpp‘,

        ‘base64.cpp‘,

        ‘hex.cpp‘,

        ‘percent.cpp‘,

        ‘shell.cpp‘,

    ],

    deps = [

        ‘//toft/base/string:string‘,

        ‘//thirdparty/stringencoders:stringencoders‘

    ]

)

你需要的只有三件事,要打造的刀叫什么刀,它需要使用什么特别的原料,它需要依赖哪些现成的原料。也就是name, srcs,deps, 换言之,就是编译对象名,编译需要的源文件,需要依赖的其它静态库。你需要描述的有且仅有他们。怎么编译,编译选项,在哪里编译,中间产物是什么,中间产物放在哪里,你通通不需要关注。刀一出鞘,东西已在那,躺在了你希望它在的所在,热乎乎的,等你去品尝。

这种简单到极致的语法,好处却有很多。比如:

1, 容易学习,容易记忆,你需要记忆的只有name, srcs,deps等掰着十指都能数的过来的关键字和规则,剩下的就是,告诉它用到哪些代码文件,用到了哪些外部的库。

相比Makefile繁琐的语法,BUILD文件可谓清爽宜人。

2,简化到了极致的好处是,各种cc_library可以在力度中间轻松转换,因此使用了BUILD文件后,模块划分会更加合理,哪怕有一个文件,其它模块可能可以使用上,你也可以方便地将它打包到一个静态库中,这样其它地方只要依赖上这个cc_library,就可以坐享其成。

我曾经见识过各种thrift文件,protobuf文件散落在代码各个目录甚至分支中,如果使用上thrift_library, proto_library,将thrift文件定义出细粒度的library,则可以避免因Makefile中频繁描述thrift/protobuf源文件生成与编译的痛苦。

羞于告诉他人的是,我至今都对Makefile不太熟悉,不过所幸,Blade已经开源,我从此不必也不像和Makefile再打交道,我也没有必要告诉别人说,我认识Makefile这个哥们。

宝刀待屠龙

江湖中向来有"武林至尊,宝刀屠龙,号令天下,莫敢不从,倚天不出,谁与争锋."的说法,blade既然是一把绝世好刀,在倚天剑面世之前,各位江湖好友,不妨试试其刀锋如何!


Blade - 腾讯开源的构建系统 c/c++编译环境

标签:

原文地址:http://blog.csdn.net/zhoubl668/article/details/50324779

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!