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

，Blade是软件project的利器。有助于模块化，模块化的力度控制自如。对于提高系统的可维护性。复杂性的隔离。代码复用的最大化。都有非常大的优点。

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

假若单元測试和代码是分离的，编译代码和执行測试各自为政，那么往往測试仅仅是測试，非常难对开发有什么帮助，由于非常多时候，尽管有測试代码，可是測试却非常少被执行，或者时过境迁后，測试多有失效。

大家假如编译过一些开源项目的话，可能就会有相似的经验。编译完静态库。拿到静态库文件就完了，非常少有人去执行全部的单元測试，确保全部的測试都能执行通过。

有了Blade，通过cc_test将gtest_main.a默认链接，使得单元測试的代码简化到极致。同一时候，主要执行blade test target,就能在编译完目标程序后。执行（并且可并发执行）对应的单元測试，以随时跟进代码是否已经偏离了该有的轨道。开发是否早已脱缰狂奔。

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

3，blade实现了递归编译。

Blade build …就可以对当前文件夹及其子文件夹下的全部编译对象进行编译。

该功能尽管小，可是却非常有用。

在一个十几人的团队中，百万行级别的代码规模。仅仅有递归编译功能。能够非常方便地实现一个循环编译工具。当某个模块编译失败。或者某个单元測试失败后，自己主动发出邮件通知相关的开发人员。以保证频繁的开发提交代码成为开发。当然，相关的功能。能够通过相似hudson之类的软件完毕。

只是blade 递归编译。对中小规模的代码而言，基本已经游刃有余。

4，blade 实现了依赖查询。

Blade query能够查询依赖到某个模块的全部模块，这个对于代码重构而言，是个不错的功能。

假如你在重构code base,或者是改动接口。或者是fix bug,或者是改进性能，

都可能使得使用到该库的相关模块。集体罢工。单元測试无法通过。

这时候，假如使用上blade query,你就可能编译相关模块。使得你提交的代码，不会给其他模块带来麻烦。

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

对整个项目而言。严把质量关非常重要，由于一旦一些烂代码进去了，清扫牛粪的工作将会非常痛苦并且艰巨。

这里的异己分子。可能包含bug,风格差异迥异等。

Blade 会在进行编译之前。会全部被变更的编码，使用指定的静态代码审查功能进行代码审查。

C++代码审查脚本。google cpplint较为知名，地址为：

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

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

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

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, easy学习，easy记忆。你须要记忆的仅仅有name, srcs,deps等掰着十指都能数的过来的keyword和规则，剩下的就是。告诉它用到哪些代码文件，用到了哪些外部的库。

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

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

我以前见识过各种thrift文件。protobuf文件散落在代码各个文件夹甚至分支中。假设使用上thrift_library, proto_library,将thrift文件定义出细粒度的library,则能够避免因Makefile中频繁描写叙述thrift/protobuf源文件生成与编译的痛苦。

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

宝刀待屠龙

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