Bazel与文件通配的CMake有同样的问题吗？

Question

我正在开始一个新项目,需要选择一个构建系统.我讨厌必须手动将每个C++源文件添加到我的构建规则中,因为它是应该在2016年之前自动执行的事情,并且在重构时会重复繁忙(重命名标题中的类,源文件,以及构建系统文件...).

当我遇到这篇文章时,我开始使用带有递归文件通配符的CMake:使用GLOB全局指定源文件？

这表明globbing是邪恶的,因为CMake使用两个阶段进行构建(cmake和make),并且在正常使用中用户只重新运行第二阶段(make).

乍一看Bazel还允许文件通配.与Bazel一起使用是邪恶的吗？运行find代码库这样的扩展问题,构建系统真的需要避免它吗？

Answer 1

Bazel没有该帖子中提到的问题,即:

(我们不建议使用GLOB从源树中收集源文件列表.如果在添加或删除源时没有更改CMakeLists.txt文件,则生成的构建系统无法知道何时要求CMake重新生成.)

Bazel将始终注意到是否从glob的匹配中添加,删除或更改了任何内容,并相应地重建.对于Bazel来说,Globbing永远不会给你带来陈旧的结果.

目前是上市需要注意几个问题和限制在构建百科全书的通配符,所以你使用水珠前,应阅读过.

此外,您可以使用bazel查询查看正在进行全局处理的内容:

bazel query '//path/to/your:target' --output=build
# /Users/kchodorow/gitroot/path/to/your/BUILD:7:1
java_library(
    name = "target",
    srcs = ["//path/to/your:A.java", "//path/to/your:B.java"],
)

这将打印"已评估"的glob,因此您可以四处游戏并查看Bazel如何跟踪输入.

Answer 2

应该发现在 Bazel 中使用 glob，它可能会导致大 glob 的长时间分析阶段，但是如果您使用 --watchfs 标志，那么将跟踪文件系统更改，监视文件系统事件，而不是声明所有文件，以便增量构建应该真的很快。