处理复杂和大型依赖项

时间:2017-08-22 20:41:15

标签: bazel

问题

我在业余时间用C ++开发了一款游戏,我选择使用Bazel作为我的构建工具,因为我从未有过很多运气(或乐趣)工作使用makecmake。我还有其他语言的依赖项(python用于某些高级脚本)。我使用glfw进行基本窗口处理和高级图形支持,并且运行良好但现在出现了问题。我不确定如何在glfw世界中处理Bazel之类的依赖关系。

对于某些依赖项(例如gtestfruit),我可以在WORKSPACE文件中引用它们,Bazel自动处理它们glfw尚未采纳Bazel。所以这一切都让我想问,我应该怎样做才能在Bazel项目中使用Bazel的依赖关系?

当前方法

对于我所拥有的许多更简单的依赖项,我只是在new_git_repository文件中创建了一个WORKSPACE条目,并为该库创建了一个BUILD文件。这很有效,直到你找到像glfw这样有很多依赖关系的非常复杂的库。

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

glfw也尝试提供基本的操纵杆支持,默认情况下在Linux中提供,这很棒!除了这是由内核提供的,这意味着内核也是我项目的依赖项。现在我不需要比内核头文件更多的内容,这仍然需要引入很多东西。

替代选项

我采用我迄今采用的方法的原因是为了创建一台能够成功构建我的游戏的机器所需的依赖项。从理论上讲,他们只需要一个C / C ++编译器,Java 8和Bazel,他们就会参加比赛。这很棒,因为这也意味着我可以创建一个安装了Docker的{​​{1}}容器,并且非常容易地执行CI / CD。

我可以牺牲这种轻松,只是说你需要在尝试编译游戏之前安装Bazel这样的库,但这会带来整个版本的安装以及如何配置所有问题备份{ {1}}应该有助于解决。

当然有一个更简单的解决方案,我是否过度思考这个问题?

1 个答案:

答案 0 :(得分:1)

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

  • glfw内构建genrule

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

  • 预构建glfw.o并将其检入源树。

    您可以为其创建cc_library规则,并将.o文件放在srcs中。尽管这种解决方案灵活性最低,因为您不仅要将目标平台限制为.o所构建的任何内容,而且还要使重建整个构建更加困难,这些好处有时也值得花费。 / p>

    我认为这种方法是最后的手段。即使在Bazel自己的源代码中也有一个cc_library.srcs that includes a raw object file,因为它是值得的,因为92caf38的提交消息解释了。

  • 要求安装glfw

    您已经考虑过此选项。有些人可能更喜欢这种做法。