有什么办法可以防止 Boost.Build 递归扫描头文件中的#include 指令？

Question

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

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

我觉得我一定遗漏了一些明显的东西，因为我无法找到其他遇到类似问题的人，尽管我几乎立即遇到了这个问题。我最接近的是here。

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

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

Answer 1

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

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

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

Answer 2

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

这是man page 的摘录。

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

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

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