用 Bazel 修剪(构建)树

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

Jonathan Lange 写了一篇关于 Bazel 如何缓存测试的 精彩博文 。基本上:如果你运行一个测试,改变你的代码,然后再次运行一个测试,只有当你改变了一些可能真正改变测试结果的东西时,测试才会重新运行。 Bazel 在很大程度上采用了这个概念来最大限度地减少您的构建需要做的工作,在某些方面并不是很明显。

让我们举个例子。假设您正在使用 Bazel 来“构建”rigatoni arrabiata,它可以表示为具有以下依赖项:

每种食物都是一个图书馆,它依赖于它下面的图书馆。假设你改变了一个依赖,比如大蒜:

Bazel 会统计“garlic”库的文件并注意到这个变化,然后记录下依赖“garlic”的东西可能也发生了变化:

这个奇特的术语是构建图的“使向上传递闭包无效”,也就是“依赖于事物的一切都可能是脏的”。请注意,Bazel 已经知道此更改不会影响几个库(通心粉、番茄泥和红辣椒),因此绝对不必重建它们。

然后 Bazel 将评估“sauce”节点并确定其输出是否已更改。这就是秘诀(哈!)发生的地方:如果“sauce”节点的输出没有改变,Bazel 知道它不必重新编译 rigatoni-arrabiata(顶级节点),因为它的直接依赖关系改变了!

sauce 节点不再“可能是脏的”,因此它的反向依赖项 (rigatoni-arrabiata) 也可以标记为干净的。

一般来说,当然,更改库的代码会更改其编译形式,因此“可能脏”节点最终将被标记为“是,脏”并重新评估(依此类推树)。但是,Bazel 的构建图允许您编译结构良好的库的最低限度,并且在某些情况下完全避免编译。