bazel - 处理复杂和大的依赖关系

Question

问题

我一直在业余时间用 C++ 开发游戏，我选择使用 Bazel 作为我的构建工具，因为我从来没有运气(或乐趣)使用make 或 cmake。我也有其他语言的依赖项(python 用于一些高级脚本)。我正在使用 glfw 进行基本的窗口处理和高级图形支持，效果很好，但现在出现了问题。我不确定我应该如何处理 Bazel 世界中的 glfw 等依赖项。

对于我的一些依赖项(如 gtest 和 fruit)，我可以在我的 WORKSPACE 文件和 Bazel< 中引用它们 自动处理它们，但 glfw 尚未采用 Bazel。所以所有这些让我想问，对于在 Bazel 项目中不使用 Bazel 的依赖项，我应该怎么办？

当前方法

对于我拥有的许多更简单的依赖项，我只是在我的 WORKSPACE 文件中创建了一个 new_git_repository 条目，并为图书馆。在您遇到非常复杂的库(如 glfw)之前，这种方法非常有效，它们自身有许多依赖项。

在为运行 X11 的 Linux 机器构建 glfw 时，您现在依赖于 X11，这意味着添加 X11 到我的 Bazel 设置。 X11 带有自己的一组依赖项(X11 库，如 X11Cursor)等等。

glfw 还尝试提供基本的游戏杆支持，这在 Linux 中是默认提供的，这很棒!除了这是由内核提供的，这意味着内核也是我项目的依赖项。现在我只需要内核头文件，这似乎仍然需要很多。

备选方案

我采用目前采用的方法的原因是，使启动可以成功构建我的游戏的机器所需的依赖性非常小。理论上，他们只需要一个 C/C++ 编译器、Java 8 和 Bazel，他们就可以参加比赛了。这很棒，因为这也意味着我可以创建一个安装了 Bazel 的 Docker 容器，并非常轻松地执行 CI/CD。

我可以牺牲这个方便，只是说你需要在尝试编译游戏之前安装像 glfw 这样的库，但这会带来安装哪个版本以及如何配置的问题Bazel 应该有助于解决这个问题。

肯定有更简单的解决方案，但我想多了？

Answer 1

如果glfw 项目没有BUILD 文件，那么您有以下选择:

• 在 genrule 中构建 glfw。

  如果 glfw 支持一些其他构建系统，如 make，您可以创建一个运行该工具的 genrule。这种方法有明显的缺点，例如必须声明该 genrule 的所有输入的不可低估的不切实际，但它是 Bazel 化 glfw< 的最简单方法.

• 预构建 glfw.o 并将其 checkin 您的源代码树。

  你可以为它创建一个cc_library规则，并将.o文件放在srcs中。尽管此解决方案是所有解决方案中最不灵活的，因为您不仅将目标平台限制为 .o 的构建目标，而且还使重现整个构建变得更加困难，但有时它的好处是值得的成本。

  我将此方法视为最后的手段。即使在 Bazel 自己的源代码中也有一个 cc_library.srcs that includes a raw object file ，因为这是值得的，作为 92caf38 的提交信息解释。

• 要求安装glfw。

  您已经考虑过这个选项。有些人可能更喜欢这种方法而不是其他方法。