《gyp构建系统介绍》由会员分享，可在线阅读，更多相关《gyp构建系统介绍（19页珍藏版）》请在金锄头文库上搜索。
1、BuildSystemPosted on 2011/09/01 by wy182000 Table of Contents 1 BuildSystem 1.1 GYP 1.1.1 设计目标 1.1.2 构建文件 1.1.3 .gyp 文件剖析 1.1.3.1 conditions 1.1.3.2 targets 1.1.3.3 includes 1.1.3.4 actions 1.1.3.5 variables 1.1.4 early and late phases 1.1.5 operator 1.1.6 路径内容属性 1.1.7 总结 1.2 Scons 1.2.1 Make 缺陷 1.2
2、.2 构建文件 1.2.3 SConstruct 文件剖析 1.2.3.1 Builder 1.2.3.1.1 编译参数和自动分析编译依赖 1.2.3.1.2 源文件使用不同参数编译 1.2.3.1.3 库链接 1.2.3.2 Dependencies 1.2.3.2.1 分析依赖 1.2.3.2.2 判断依赖变化 1.2.3.3 Environment 1.2.3.4 Hierarchical Builds 1.2.4 其他问题 1.2.5 总结 1.3 Ninja 1.4 ABS 1.5 CMake 1.5.1 构建文件 1.5.2 CMakeLists.txt 解析 1.5.3 变量和属
3、性 1.5.4 注释 1.5.5 编译类型 1.5.6 生成 config.h 1.5.7 Makefile 1.5.8 总结 1.6 Others 1.7 个人感觉 1 BuildSystem words from (leemars528) 内部构建系统*必须*要求所有模块都使用这个构建系统。 模块的依赖*不应该*通过额外的系统来管理。 *应该* 能够指定足够细致的粒度。 就*应该* 只依赖于需要生成接口所需要的最少内容。1.1 GYP gyp(generate your project)是 chromium 的构建系统，地址在http:/ GYP 和 CMake 的对比在 http:/ w
4、ork 成功。虽然 wiki 有UserDocumentation 但是里面介绍非常粗略，基本上可以认为是一个没有成熟产品。虽然没有比较好的使用文档，主页 wiki 里面还有有一些关于 gyp 本身比较好的描述，以及设计的初衷。 通过学习这些内容，可以对构建系统有更加深入的认识。感谢(leemars528)给我的建议， 他透露这个可能是 gg 内部的一个构建系统原型。并且之前 (from google)给我举构建系统例子的时候， 表达方式上和 gyp 也非常相似，所以有理由相信 gyp 很像现在 google 内部的构建系统。1.1.1 设计目标 gyp 设计针对目标就是为了解决 chromi
5、um 浏览器构建问题，最重要的就是支持多平台的构建。因此生成的后端可能是 Scons/Make(Unix/Linux)，Xcode(Mac)或者是 Visual Studio(Windows).并且因为 chromium 内部都是 C/C+文件， 因此主要考虑方便 C/C+程序的构建。设计时候还考虑到下面这些问题： debug vs. release. cross compile. toolchain interface.1.1.2 构建文件 构建文件名字不固定，但是后缀通常是.gyp 和.gypi(gyp included).构建文件内容就是python 的一个数据结构 (可以认为是 jso
6、n,不过允许#作为注释并且允许 trailing 的). 这样做的一个方便结果就是为了读取构建文件信息， 只需要 eval 一下文件的内容即可，就可以得到这个构建文件的描述了。下面是一个 example：target_defaults:defines:DEBUG, ,targets:target_name:test, #生成的文件.type:executable, #可执行程序.sources:test.cc,defines:FOO 在后面部分会详细解释构建文件里面的每个 element。1.1.3 .gyp 文件剖析 整个构建文件最顶层是一个字典，包含了下面这些 key： condition
7、s /条件判断 includes /包含的构建文件 targetdefaults /构建目标默认属性 targets /构建目标列表 variables /构建文件使用的变量1.1.3.1 conditions conditions 分为两种行为。普通的 conditions 就在 load 构建文件之后立即计算，另外一种是targetconditions是在计算完成依赖之后然后来进行计算的，两个过程分别就是 early and late phases 阶段。对于 conditions 写法非常简单：conditions:OS=Linux,sources:linux_interface.cc对
8、于 condition 的判断，主要还是为了能够修改一些描述属性。从文档上来看的话，默认提供的条件就是 OS 判断，其他判断应该都是变量的判断。1.1.3.2 targets target 部分的话会对 targetdefaults 里面设定的内容默认进行 merge。比如上面例子的话，对于 target/test 来说， 使用的 defines 就会是-DDEBUG -DFOO。当然对于这种东西是可以进行其他策略选择的，比如如果修改成下面格式，那么就是直接替换：defines=:FOO生成的 defines 就是-DFOO 了。或者是可以剔除掉：defines!:DEBUG生成的 defin
9、es 就没有任何内容了。通过在选项 key 后面添加操作符号来达到自定义目的( 相对于全局环境).对于一个 target 包括了下面这些重要属性： actions(list) /执行命令 alldependentsettings(dict) /如果依赖这个 target 的话，需要使用的设置 configurations(dict) /配置 defines(list) /对于 C/C+的 defines dependencies(list) /依赖对象。如果是本文件的话那么直接引用，如果是其他文件的话，使用 path/xxx.gyp:target. directdependentsetting
10、s(dict) /直接依赖这个 taregt 的话，需要使用的设置 includedirs(list) /头文件目录 libraries(list) /目标需要链接的库 linksettings(dict) /依赖这个 target，需要使用的链接参数 sources(list) /源文件 targetconditions(list) /和 conditions 类似，但是是在完全计算之后然后来判断 targetname(string) /名字 type /目标类型，现在只是支持 staticlibrary,sharedlibrary,executable 和 none1.1.3.3 incl
11、udes gyp 倾向的组织就是在 toplevel 上面存在一个 gyp 文件，可以存在子目录下面，但是子目录下面并不存放一个完整的构建文件， 通常只是存放构建文件的片段。为了区分，后缀为gypi。本身来说，这个 gypi 并不可以直接被 gyp 所接受生成 native 构建系统文件， 唯一的作用就是被 toplevel 的 gyp 文件进行 include。如果对于 Linux 系统来说，最终生成的Makefile 应该是一份大 Makefile 并且没有递归 make 的操作。 关于构造一个没有递归的Makefile 是非常有价值的，不管是对于调试还是提升编译速度方面。可以参考文章 R
12、ecusive Make Considered Harmful.一旦我们允许 include 子目录的 gypi 文件进来，我们就必须规定哪些字段应该是文件。原因是假设存在 src 目录下面有 src/BUILD.gypi 这样一个文件，sources 内容如下:sources:src.cc而在上层 BUILD.gyp 文件里面，使用 includes 语法：includes:./src/BUILD.gypi那么在生成大 Makefile 的时候，我们必须清楚 sources字段里面内容都是文件，不应该直接使用 src.cc， 相反应该加上目录前缀 src，最终应该使用 src/src.cc
13、这样一个文件。关于哪些字段里面内容是路径， 这个在 gyp 里面有详细规定，在后面小节里面我们也会提到。1.1.3.4 actions actions 是 targets 里面的一个特殊属性，主要是用来进行 target 的自定义操作的。关于rule 的部分， 应该问问 ,因为他实际操作过 gyp 并且阅读过Chrmoium 里面的 .gyp 文件。每个 action 是一个 dict，主要包含 4 个属性： actionname(string). /操作名称 input(list) /输入文件 outputs(list) /输出文件 actions(list) /命令有了这些属性就可以做一个
14、完整的操作抽象。1.1.3.5 variables variables 这个小节里面是进行变量的定义，格式是 dict。下面是一个例子：variables:common_files:src/common.cc,src/interface.cc,为了引用变量，我们可以这样编写：(common_files)(common_files)总之引用变量必须加上(),同时在前面加上,的 4 种中一种前缀符号。关于前缀符号的含义， 会在后面的 operator 小节里面说明。对于变量类型，一共分为 3 类： predefined variables /预定义变量 user-defined variables
15、 /用户定义变量 automatic variables /自动变量预定义变量比如 OS(系统环境),EXECUTABLE SUFFIX(可执行文件后缀).用户自定义变量就不再赘述。自动变量类似于 Makefile 里面的 $,$这样的变量，好比反射。比如在 targetconditions 部分的话， 我们根据不同类型程序来做不同的condition：target_conditions:_type=static_library,sources:func.cc这样对于 target 为 staticlibrary 都会联编 func.cc 这个文件了，自动变量是就是属性名称之前加上 构成的。存在自动变量非常必要。有时候我们在全局环境中，希望根据不同的条件来定义不同的行为，并且是在计算的同
