最佳做法

<ph type="x-smartling-placeholder"></ph> 报告问题 查看来源 敬上 每晚 · 7.3。 · 7.2 条 · 7.1 · 7.0 · 6.5

本页面假定您熟悉 Bazel,并提供了 有关构建项目以充分利用 Bazel 功能的建议。

总体目标是:

  • 使用精细的依赖项来支持并行性和增量性。
  • 为了确保依赖项得到妥善封装。
  • 确保代码结构合理且易于测试。
  • 创建一个易于理解和维护的 build 配置。

这些指南并非强制性要求:很少有项目能够遵循 所有资源正如 lint 的手册页面所述, 让第一个人生成真正的程序,并且该程序不会产生任何错误。 严格检查。”不过,在尽可能多地结合这些原则时, 应该可以提高项目的可读性、不易出错和构建速度。

本页面使用 此 RFC

运行构建和测试

项目应始终能够运行 bazel build //... 和 已成功在其稳定分支上执行 bazel test //...。目标必不可少 但在某些情况下(例如,需要特定的 build 时) 标志、不要在特定平台上构建、需要许可协议) 尽可能具体地标记(例如“requires-osx”)。这个 标记可让您在比当前标签更精细的级别过滤目标 “手动”标记后,检查 BUILD 文件的人员就能了解 目标的局限性

第三方依赖项

您可以声明第三方依赖项:

  • WORKSPACE 文件中将其声明为远程仓库。
  • 或者将它们放在工作区目录下名为 third_party/ 的目录中。

依赖于二进制文件

所有内容都应尽可能从源代码构建。一般来说,这意味着 这样,您便不再依赖于 some-library.so 库,而是创建一个 BUILD 文件并从其源代码构建 some-library.so,然后依赖于它 目标。

始终从源代码构建可以确保构建不使用 是使用不兼容的标志或其他架构构建的。还有 覆盖率、静态分析或动态分析等 源代码工作

版本控制

最好尽可能从头构建所有代码。版本必须 请避免在目标名称中包含版本(例如 //guava、 而不是 //guava-20.0)。此命名使库更易于更新(只有一个 目标需要更新)。对菱形依赖项的适应能力也更好 问题:如果一个库依赖于 guava-19.0,而另一个库依赖于 guava-20.0, 最终可能会出现一个尝试依赖于两个不同版本的库。 如果您创建了误导性别名,将两个目标指向一个 guava 库, 那么 BUILD 文件具有误导性。

使用 .bazelrc 文件

对于特定于项目的选项,请使用您的 workspace/.bazelrc(请参阅 bazelrc 格式)。

想要支持您按用户设置的项目 想要签入源代码控制,请添加以下代码行:

try-import %workspace%/user.bazelrc

(或任何其他文件名)中的workspace/.bazelrc 并将 user.bazelrc 添加到 .gitignore

软件包

每个包含可构建文件的目录都应该是一个软件包。如果 BUILD 是指其子目录(如 srcs = ["a/b/C.java"])中的文件, 指示应将 BUILD 文件添加到该子目录中的符号。越长 循环依赖关系 无意间创建,目标的范围将逐渐扩大, 必须更新反向依赖项。