如何延迟 SCons 源扫描器的运行？答案

【问题标题】：How to delay the run of SCons source scanner?如何延迟 SCons 源扫描器的运行？
【发布时间】：2017-08-30 10:47:34
【问题描述】：

我设置了一个 SCons 构建系统，用于从 C++ 构建一些库，以及通过 SWIG 为它们构建的 Python 包装器。然后将结果用于数据处理，这也是 SCons 构建的一部分。数据处理是使用已构建的 SWIG 包装库的 Python 脚本。

我已经设置了依赖关系，以便在构建所有库和包装器之后开始数据处理，并且效果很好。但是有一个警告（你猜对了，对吧？:)）。我想添加一个源扫描器，它还使用一些 SWIG 库来扩展依赖项。问题是扫描仪运行得太快了。事实上，我看到它运行了两次——一次是在构建早期的某个时间点，另一次是在数据处理开始之前。因此，并行构建的第一个扫描仪通常发生在构建所有必要的库之前，因此它失败了。

如何使扫描仪本身依赖库目标？

或者，我可以延迟扫描仪运行 - 或取消第一次扫描仪运行吗？

还有其他想法吗？

【问题讨论】：

那么你要做的是用scons构建一个python模块（编译），然后在scons中加载那个模块并使用它？
是的，基本上。仅在扫描仪中使用它，而不是在构建配方本身中使用。如果扫描仪只在构建目标之前运行，它会正常工作。

标签： python build dependencies scons

【解决方案1】：

这是另一种潜在的解决方案，它是另一种解决方法。如果 *.i swig 接口文件作为“节点”参数传递给它，扫描器是否可以推测将生成的文件列表？这样，扫描程序实际上并不需要存在文件来生成依赖项列表。

一般来说，我想知道这个问题的解决方案是否只是在实际生成 SWIG 库之前编写逻辑来积极推测依赖关系。我不认为通过查看“_*.so”文件本身可以获得太多信息。

【讨论】：

扫描器“节点”自动地是来自关联构建器设置的每个源文件，一个接一个，加上发射器产生的任何东西。如果缺少 Scanner 输入指定的内容，则构建失败。而且您仍然无法在该扫描仪中使用 SWIG 库。
是的，但是，我的理解是 scons 实际上并不需要存在依赖项。如果以前的构建器将这些文件作为其目标之一，scons 将愉快地执行构建，因为它已承诺扫描器指示的相关依赖项将由构建器生成，该构建器将在与扫描器对应的构建器之前运行。

【解决方案2】：

一种解决方法我认为 可行的方法是将扫描仪转变为运行扫描过程而不是扫描仪并生成列出所有依赖项的文件的构建器。然后，数据处理构建将只需一个扫描仪来解析该文件。我希望 SCons 不会尝试过早运行它，因为它会意识到扫描的源文件是某些构建器的目标。

假设它有效，它仍然是一个低于标准的解决方案，因为它使构建设置复杂化并添加了一个不太小的文件的额外文件 I/O（依赖项是数千个文件，路径很长）。

【讨论】：