build-system

gyp设计针对目标就是为了解决chromium浏览器构建问题，最重要的就是支持多平台的构建。因此生成的后端可能是 Scons/Make(Unix/Linux)，Xcode(Mac)或者是Visual Studio(Windows).并且因为chromium内部都是C/C++文件， 因此主要考虑方便C/C++程序的构建。设计时候还考虑到下面这些问题：

• debug vs. release.
• cross compile.
• toolchain interface.

构建文件名字不固定，但是后缀通常是.gyp和.gypi(gyp included).构建文件内容就是python的一个数据结构 (可以认为是json,不过允许#作为注释并且允许trailing的).这样做的一个方便结果就是为了读取构建文件信息， 只需要eval一下文件的内容即可，就可以得到这个构建文件的描述了。

下面是一个example：

{
    'target_defaults':{
        'defines':['DEBUG'],
    },
    'targets':[
        {
            'target_name':'test', #生成的文件.
            'type':'executable', #可执行程序.
            'sources':['test.cc'],
            'defines':['FOO']
        }
    ]
}

在后面部分会详细解释构建文件里面的每个element。

整个构建文件最顶层是一个字典，包含了下面这些key：

• conditions //条件判断
• includes //包含的构建文件
• target_defaults //构建目标默认属性
• targets //构建目标列表
• variables //构建文件使用的变量

对于变量展开和条件判断有两个不同的阶段：

• 载入文件之后进行，就是early phase。
• 计算完成之后进行，就是late phase。

对于两个阶段允许不同操作是非常必要的。对于early phase这个肯定需要，而对于late phase的话， 有时候我们是希望了解到gyp处理完成某个target之后所有信息，然后进行判断的。

ps:comake2在设计的时候，就没有考虑late phase这个功能。造成没有办法在应用层添加延迟计算这样一个特性。 最终只能够是修改comake2代码来完成需求。

关于每个操作符号的含义：

• x= //字段内容进行覆盖
• x? //如果字段没有定义，那么就进行覆盖
• x+ //字段内容进行merge
• <(x) //early phase计算变量x，并且以string类型返回结果
• >(x) //late phase计算变量x，并且以string类型返回结果
• <@(x) //early phase计算变量x，并且以list类型返回结果
• >@(x) //late phase计算变量x，并且以list类型返回结果
• x! //从已有的x字段中排除部分
• x/ //操作允许使用include/exclude，内容是一个正则表达式来进行包含和排除列表里面内容
• <!(x) //认为x是一个shell command，得到执行结果作为string类型返回
• <!@(x) //认为x是一个shell command，得到执行结果作为list类型返回

在includes这个小节提到了，gyp规定了某些属性的内容必须为路径。这些属性是：

• files.
• include_dirs.
• inputs.
• libraries.
• outputs.
• sources.

但是gyp对于里面的内容也做了一些特殊处理。对于内容来说，如果以下面这些字符开头：

• / //绝对路径
• $ //变量
• - //链接参数比如-lm
• <,>,! //operator
• 其他作为相对路径

gyp文档缺乏导致在分析这个系统的时候，也没有完全使用只是通过阅读文档来完成的，没有一个可以run的Makefile。 同时Makefile也想当难读(尽管如此，还是稍微看了一下生成的Makefile).最好可以结合chromium源代码来看看gyp是如何使用的(时间有限,我没有做).

gyp虽然是构建系统，并且通常来说构建文件倾向于使用描述性语言来完成，但是类json风格的描述性语言很容易形成过深的嵌套不利于阅读。 可以考虑使用其他方式描述性语言来完成。如果可以的话，结合过程语言也未尝不可。

在运行时上gyp区分early和late phase两个阶段，同时允许通过target_defaults这样一个section来设定全局属性。 通过automatic variables这样的机制提供了反射功能，并且允许自定义操作，并且允许从外部shell中读取内容。 此外gyp允许提供跨模块之间的依赖管理(一个模块有如何这个模块被依赖的话，那么依赖这个模块的模块应该使用哪些属性). 这些都是一个强大构建系统所必须的。

从gyp层面就考虑了如何避免调用recursive make，通过规定某些属性内容只允许为路径名称并且允许include其他目录的.gpyi文件， 理论上可以生成不需要recurisve make的Makefile。同时在生成Makefile上面考虑了cross compile,out-of-source build问题。

SCons对于Make缺陷也有一个总结，链接是http://scons.org/wiki/FromMakeToScons。 这里稍微总结一下，在设计Make代替品BuildSystem时候需要考虑到：

• make的命令是不可移植的，也就是说，对于*nix和win32必须单独编写不同的make命令。
• make对于递归目录处理会牺牲速度。同时从目录角度来说，可能会发生重复检查的情况。
• make语法十分ugly。
• make使用环境变量，这样造成很多问题不可复现。
• make对于一些检查过于简单，造成很多时候你必须make clean然后重新make。
• make缺乏自动分析编译依赖。
• make难以调试，主要是在规则冲突方面。

客观地说除了3之外，其他都是非常严重的问题。对于3的话，要看你使用Makefile到什么程度了。 除了这些之外，如果按照Ninja的说法来说，Makefile还有一个速度过慢的缺点。

scons的构建文件名称是统一的都称为SConstruct。当然为了方便目录的组织，也允许在各个目录下面存放SConscript， 然后最上面SConstruct收集这些SConscript组织成为一个大的构建文件。

和gyp所不同的是，scons并没有生成一个所在平台的构建系统文件(linux->Makefile)，而是直接解释SConstruct来进行构建。 避开native build system文件的生成在一定程度上可以简化工作量，但是自己需要来完成整个构建活动。 同时速度可能会打一些折扣(比如现在google推出的ninja的构建系统构建系统很好，而scons就不能有效利用这个工具,而gyp只需要稍加改动就支持). 个人观点来看的话，生成native build system文件可能是一个更好的选择。

下面是一个简单例子

Program('main.cc')

然后使用方式是

[zhangyan@tc-cm-et18.tc.baidu.com test-scons]$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -o main.o -c main.cc
g++ -o main main.o
scons: done building targets.

使用scons默认用来构建里面所有的内容。当然也可以使用scons <target>来构建某个或者是某些target。 scons -c相当于make clean,scons -Q的话可以安静地构建，只是打印出真正执行的命令。

如果是需要编译多个文件的话,可以使用python的列表格式。同时这些scons内置函数也是支持python的keyword argument这样的形式的：

Program(target='hello',source=['main.cc','hello.cc'])

然后我们执行

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -o main.o -c main.cc
g++ -o hello.o -c hello.cc
g++ -o hello main.o hello.o
scons: done building targets.

我们可以看到，在这个SConstruct这个Python Script里面Program等东西都实现成为了scons的内置函数， 然后在表达上文件列表就是使用python列表形式。这样在一定层面上这就让用户接触到了[]这样的格式， 用户可能就会意识到当前可能是一个脚本，而不是以一种透明方式展现出来。不过通常来说,这样问题并不是很大， 用户也能够忍受列表以及keyword argument这样的东西，同时对于高级用户(熟悉python)的人也感到比较亲切。

同时我们必须注意到，scons在构建目录下面存放了一个.sconsign.dblite这样一个文件。这个文件应该是 使用sqlite这样关系数据库的。因为scons很多特性需要依赖存储数据，比如cache隐式依赖，记录文件的md5等等信息， 单独使用一个辅助文件存放信息是一个不错的选择。

scons提供了install方法，允许把某个文件安装到某个目录下面去，以相同或者是不同的名字安装。

scons提供了平台无关的文件操作函数，比如copy,delete,rename,mkdir,touch等。这些函数做成为一个延迟函数对象. 有一个Execute函数可以接受这些对象立即执行。其实关于这文件操作函数，个人认为可能完全没有必要，平台无关是非常好的概念， 但是对于文件系统实在是难于抽象出来。其他不说，首先考虑文件系统的名称就够费神半天，个人觉得把大部分细节屏蔽掉就ok。 对于需要平台相关操作,那就平台相关命令吧，scons对于命令操作也包装成了一个对象，这样可以延迟执行。

scons支持out-of-source的编译方式，实现方式是通过copy源代码到另外一个地方然后进行编译，关于这么做的原因在下面地址也说了。 个人感觉，可能out-of-source的编译也不一定需要使用这种方式来完成(Android Build System就是out-of-source编译的,但是没有copy source). http://www.scons.org/doc/2.1.0.alpha.20101125/HTML/scons-user/c3348.html

scons支持configure这样的功能，包括：

• 检查头文件是否存在
• 检查库是否存在
• 检查typedef
• 检查函数是否存在

当然这只是配置中一部分。阅读了MongnoDB的SConstruct这个文件，发现其实还有相当多的检测是需要自己来完成的， 同时可能不希望按照scons内置的configure规则来进行检查。对于configure这样一个东西是非常需要，但是相当难做。 GNU Autoconf个人感觉来说相对更加成熟一些，如果一定要做configure这样功能的话，可以首先参考一下GNU Autoconf.

scons还支持cache编译产出物这样的功能，不过个人还是觉得没有必要这么做，因为这样在scons内部实现了一个cache系统， 不仅仅加重了工作量，而且并没有做好，因为相对ccache来说，scons提供过于简单了。至于cache效率的话，是另外一个问题。 关于cache系统确实完全独立实现并且通用。

scons是一个文档相对来说比较完整，已经被一些大型项目所使用的，比较成熟和完善的产品。

scons本身使用Python Script来做描述文件，相对于gyp来说可读性会更好，表达功能上相对于gyp也更加强大， 但是容易造成一个问题就是速度会过慢，尤其对于scons这种执行方式。因为scons每次都是读取SConstruct/SConscript文件， 而不像gyp一样一次就生成Makefile，大部分时候是不需要变动Makefile，只是需要make的。

scons对于编译依赖来说，提供了隐式分析和显示说明两种方式来描述依赖，然后针对隐式分析编译依赖也做了一些有效的优化。 comake2在这点上也是提供了隐式分析和显示分析，但是却没有做一些优化，这样就造成每次生成Makefile时间过长。 如果是大型项目，耗时会非常长，在这些情况下面显示编写依赖可能会更好。对于依赖变化检测，也是提供了很多种方法。 并且如果构建参数发生变化，也是认为依赖发生变化，重新构建的。

scons对于构建系统构建方式，和gyp一样认为构建必须从top-level开始进行。 和gyp一样，允许每个子目录下面存放SConscript描述文件，然后在上层最终收集上来。

scons提供了环境这个概念，这点对于构建不同参数的版本作用非常大。并且scons对于环境这个概念引入也非常自然， 直接env.Program(..)和没有使用环境的Program(..)在编写内容上相差无几，同时也提供了很多关于环境的操作，并且提供一个默认环境。

和其他构建系统一样，scons还提供了平台无关文件操作，install方法，out-of-source编译，configure，以及编译产物的cache， 不过个人看来其实每个部分要不就做得相当粗糙(out-of-source编译,configure)，要不就是鸡肋(文件操作，编译产物cache，install)， 当然也可能是因为自己对于scons了解不够深入引起的。

编写一个简单的CMakeLists.txt非常简单：

project(main)
add_executable(main main.cc)

然后进行configure并且同时生成Makefile：

[zhangyan@tc-cm-et18.tc.baidu.com test-cmake]$ cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /home/zhangyan/utils/bin/gcc
-- Check for working C compiler: /home/zhangyan/utils/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/zhangyan/test-cmake

输入参数指定source位置，这样来进行out-of-source的构建。cmake在第一次分析CMakeLists.txt的时候， 会对环境进行分析然后将一系列得到的环境内容保存在CMakeCache.txt文件里面，得到一系列的变量，相当于配置的选项。 然后外部允许通过自己指定来改写这些默认得到的环境，但是这个环境依然不能够被source所使用，比较好地可以被程序使用的方式， 就是像GNU Build System一样生成的config.h。关于如何生成config.h，会在特定的节里面提到。

[zhangyan@tc-cm-et18.tc.baidu.com test-cmake]$ make
[100%] Building CXX object CMakeFiles/main.dir/main.cc.o
Linking CXX executable main
[100%] Built target main

cmake本身也提供了类似于gyp的功能,将编译依赖输出graphviz的图,方便查看.

cmake里面提供的描述语言，内置了函数，宏，条件判断，流程控制，同时还有变量(不清楚是否有嵌套作用域)， 还有一些简单的数据结构比如整数字符串以及列表，相当的完整。

关于CMake有相当多的语法和属性，这里就不一一讲解，只是谈谈相对于其他构件系统比较独特的地方。

add_custom_command允许用户进行自定义的命，通过指定output,input,command，同时允许指定这些命令在：

• dependencies构建之前执行
• dependencies构建之后，但是target构建之前执行
• target构建之后执行

add_test允许全局环境增加test用例，允许自己使用test的启动命令。

build_command能够获得某个target的构建命令。

file定义了一系列文件操作方法，为多平台的文件操作提供了抽象。

find提供了一系列查找文件，库，package，program的方法，简化配置的生成。 对于find_package内置很多检测库的方法，并且有大量的内置变量可以被使用。

set_property/get_property设置和获取属性。

include包含另外一个文件进来，语义和Make的include是一样的。而add_subdirectory添加一个子目录，对应的Makefile就是"make -C …"。 从效果上说，cmake并没有提供类似于gyp和scons的import功能来方便进行项目的整体构建，还是将一个个目录单独进行构建。

变量和属性其实是一个概念，我们使用$<…>来进行变量引用，而使用set来设置变量。对于里面的内容，语法如下：

OPTION:target

引用target下面的某个OPTION。这些就可以针对每个target来进行一些参数定制了。比如：

SET(cppflags:libecho.a,"-DDEBUG -W -Wall")

注释也作为属性存在于target或者是全局环境中.对于target的注释来说，在进行build的时候，cmake能够让注释在执行命令之前就显示出来。 这样一方面可以利于开发者来进行调试，同时产生的输出信息对于用户也更加友好。

cmake的编译类型一共分为4类，可以简化编译选项的设置：

• Debug //调试版本
• Release //发布版本
• RelWithDebInfo //发布版本但是带上调试信息
• MinSizeRel //发布版本但是简化二进制大小

可以通过-DCMAKE_BUULD_TYPE=…在命令行里面指定.使用一个编译类型会配置上一系列的编译选项，用户可以在内部继续修改这些选项。

写到这里，关于选项这种东西，有一些想法。在设计选项方面，我们必须考虑下面这几个功能：

• 选项必须进行分配，然后可以进行批量开启。
• 允许用户在描述文件中覆盖和增加选项。
• 允许用户在命令行也指定这些选项。

这样在易用，功能方面能够达到比较好的折衷。

cmake生成config.h的方法也是套用模板的方式。里面提供了一个函数，可以将类似于：

#define JPEG_FOUND %{jpeg_found_value}d

然后在cmake运行时环境里面存在jpeg_found_value这样变量进行替换，然后生成config.h。 非常不错的idea(猜想GNU Build System应该也是这样完成的).

生成的Makefile，包含下面这样几个大的target：

• make //默认构建
• make <target> //构建某个target
• make clean //删除中间构建结果
• make depend //重新计算依赖
• make <source>.ii / <source>.s // <source>.o //生成中间文件

cmake能够自动分析C/C++的编译依赖。同时如果CMakeLists.txt发生变化的话，那么也会重新生成Makefile。 因为时间有限，对于生成的Makefile也没有仔细分析。

是一个相当成熟的项目，并且有一系列的外围和cmake形成一个整体，内置了相当多的辅助函数来帮助使用其他开源的库， 所以在设计和实用性上可以看得出来是相当严肃的。

因为语法是自己定义的语言，所以学习起来有一定的成本。在描述能力上来说还是不错的， 但是缺乏一些高级的数据结构比如字典可能会造成某些情况下面使用比较麻烦。

同时cmake还提供一系列检测环境的能力，然后通过生成config.h来进行source file configuration。

最后生成的Makefile在构建时候，用户友好方面不错。并且在CMakeLists.txt变化以及源文件依赖的.h文件变化的话， cmake会重新生成Makefile并且进行编译的。不过因为时间有限也没有对Makefile进行仔细的分析。