5

有没有办法将 Boost.Build 递归扫描 #include 指令的头文件限制到特定目录或目录集？即我希望它只递归地扫描我的项目中的头文件。我知道它们的外部依赖项不会改变（而且作为 Boost 和 Qt，它们非常大）。我最终在依赖关系树中有大约 50,000 个目标，这需要一段时间来处理（即使没有文件实际更改，也会导致 1-2 分钟的构建时间）。

到目前为止我发现的唯一解决方案是利用 INCLUDE 环境变量（我正在使用 MSVC） - 这意味着 Boost.Build 不需要被告知包含路径（我正在使用该功能），因此将不要扫描它们。这似乎有点骇人听闻。

我觉得我必须遗漏一些明显的东西，因为我无法找到其他遇到类似问题的人，即使我几乎立即遇到了这个问题。我来的最近的地方就是这里。

从调试输出（bjam -d 3）来看，它还会多次扫描大多数头文件......我不知道这是否意味着它们被多次添加为依赖项，但肯定是加载的成本文件和扫描的全部内容必须加起来吗？

如果我可以告诉它不要费心扫描特定目录或目录集，我可以保证头文件不会更改，那将是完美的。

4

2 回答 2

3

这个问题也发布在 Boost 邮件列表中，我们在这里得到了答案：http: //lists.boost.org/boost-build/2009/04/21734.php。

所以到目前为止，答案似乎是，至少开箱即用，Boost.Build 没有这个功能，解决方案是根据您的需要自定义 Boost.Build，这有一定的意义。

但是，我仍然很好奇为什么这对人们来说不是一个更常见的问题。我看到缓存依赖项会减少时间，但是如果我们扫描所有外部库，我们最终会得到一个巨大的依赖项树，其中大部分是多余的吗？当我在做一个项目时，我根本不会经常更改第三方库，为它们的依赖检查付费似乎是一种耻辱。

于 2009-04-27T23:50:37.557 回答
1

您可能想查看替代构建工具，例如SCons。SCons 有一个模式--implicit-cache缓存隐式依赖项。这应该有助于您描述的场景。

这是手册页的摘录。

--implicit-cache
缓存隐式依赖项。这会导致 scons 使用上次运行时的隐式（扫描）依赖项，而不是扫描文件以查找隐式依赖项。这可以显着加快 SCons，但有以下限制： scons 不会检测对隐式依赖搜索路径（例如 CPPPATH、LIBPATH）的更改，这些更改通常会导致使用不同版本的同名文件。如果在隐式依赖搜索路径（例如 CPPPATH、LIBPATH）中比当前同名的隐式依赖更早地添加了新的隐式依赖，scons 将错过隐式依赖的更改。

--implicit-deps-changed
强制 SCons 忽略缓存的隐式依赖项。这会导致重新扫描和重新缓存隐式依赖项。这意味着 --implicit-cache。

--implicit-deps-unchanged
强制 SCons 忽略隐式依赖项中的更改。这会导致始终使用缓存的隐式依赖项。这意味着 --implicit-cache。

于 2009-04-22T19:24:09.077 回答