输出文件.PPTVIP

02 Part Two Google是如何描述驱动构建和测试的依赖关系的呢？ 描述方式 Google把代码划分成被称为包[package]的小单元。可以把包理解为一个目录，这个目录里面包含了源文件和一个描述文件，描述文件中指定了如何将源文件转换成构建的输出。这个描述文件叫做 BUILD，一个目录中存在这个BUILD文件，就可以把这个目录当作一个包。 所有的包都在同一个文件树下面，使用从文件树的根到包含BUILD文件的目录的相对路径来做为这个包的全局唯一的标示。这说明包名和目录名之间是一一对应的关系。 在BUILD文件中我们用规则[rules]来描述构建后包的输出。使用包名和规则名称可以唯一的标示这条规则。我们把这两者的结合叫做标签[label]，我们使用标签来描述规则之间的依赖关系。 构建步骤 把每个规则分解成一个或多个实际的步骤，称之为行为[actions]. 可以把行为理解为一条命令和输入／输出文件。一个行为的输出可以是另外一个行为的输入。这样所有的行为就形成了由行为和文件组成的二分图。为了构建目标所需要做的就是从这个二分图的叶子节点--那些不需要任何行为来创建就已经存在的源文件--遍历到根节点并顺序执行这些行为。这保证在执行一个行为之前，相关的所有输入文件都已经就位了。 为了真正执行构建所需的步骤，我们把每个规则分解成一个或多个实际的步骤，称之为行为[actions]. 可以把行为理解为一条命令和输入／输出文件。一个行为的输出可以是另外一个行为的输入。这样所有的行为就形成了由行为和文件组成的二分图。为了构建目标所需要做的就是从这个二分图的叶子节点--那些不需要任何行为来创建就已经存在的源文件--遍历到根节点并顺序执行这些行为。这保证在执行一个行为之前，相关的所有输入文件都已经就位了。 一个小规模目标组成的行为二分图的例子如右图所示，行为是绿色，文件是黄色。 03 Part Three 分布式执行构建的步骤 步骤一 构建系统是基于内容的，系统内部对于输入和输出是通过基于内容的摘要来标记的，而不是文件和时间戳（例如Make）。这意味者通过比较内容摘要就能知道内容是否是相同的，构建系统在根据行为图来执行构建操作时，会把这些摘要在内部记录下来。在构建过程中为大量的源代码计算内容摘要会很耗时，主要时间都花在读取文件上。通过在内容提交的时候计算并存储摘要就可以避免这个问题，之后直接通过文件扩展属性来提供给构建系统。 步骤二 构建系统通过读取BUILD文件来构建一张依赖关系的图，然后使用依赖关系图去构建一个 构建行为 或构建步骤的图。通过使用行为的输出作为其他行为的输入来构建这个依赖关系图。依赖关系必须是完整指定的，而且不能有动态的依赖检测。内容摘要和指定的完整依赖意味着行为可以通过函数来表示。 * * * * * * * * * * * * * * * * * * * * * * 自动化构建工具Bazel PPT模板下载：/moban/ 行业PPT模板：/hangye/ 节日PPT模板：/jieri/ PPT素材下载：/sucai/ PPT背景图片：/beijing/ PPT图表下载：/tubiao/ 优秀PPT下载：/xiazai/ PPT教程： /powerpoint/ Word教程： /word/ Excel教程：/excel/ 资料下载：/ziliao/ PPT课件下载：/kejian/ 范文下载：/fanwen/ 试卷下载：/shiti/ 教案下载：/jiaoan/ PPT论坛： Bazel 应用背景 工作方式 构建步骤 结果分发 01 Part One Bazel的应用背景 GOOLE的产品开发模式 所有的产品都是 在主干上开发的。 产品开发的国际化 问题：位于世界各地的开发中心从从主干上下载代码的时间差距巨大。 原先的解决方案 缺点：计算依赖关系也要耗费相当长的时间 同时会增加系统的复杂度，因为要在文件控制系统的层面上与版本控制工具进行的精密耦合。 延迟符 问题的产生 01 优点：每个人都可以查看和修改代码，避免了在分支上长时间开发后合并主干时候的痛苦，同时也避免了库之间的二进制兼容问题。 拥有位于世界各地的开发中心 通过计算依赖关系限制下载文件数量 研究表明 我们发现工程师下载代码后修改的代码相对于执行构建需要的代码而言是非常小的一部分。因为我们所有的东西都是从代码构建的，而修改的只是源码树中的一小部分。 工程师和自