【发布时间】：2010-09-14 10:27:35
【问题描述】：
我目前正在使用基于 SCons 的构建系统，我不负责维护，但可以向维护者提供输入。
其中一个问题是处理 C++ 源包之间的依赖关系。在系统中，每个源码包在 Windows 上构建为 DLL，在 Linux 上构建为共享库。
假设包 A 包含对包 B 和 C 的依赖项。B 和 C 在包 A 的 SConscript 中指定。这可以。包 A 的 DLL 也将与 B 和 C 的 DLL 链接。这也很好，因为在构建这些 DLL 时已经解决了 B 和 C 的任何链接依赖关系。
复杂性来自具有与之关联的单元测试的包。这里我们需要知道完整的、递归扩展的库依赖列表，主要有两个原因：
- 构建单元测试涉及创建一个设置 PATH 并调用可执行文件的脚本。每个运行时依赖项都需要在 PATH 中添加一个条目。
- 链接 Linux 上的单元测试可执行文件需要完整的扩展库依赖项列表。这与 Windows 不同，在 Windows 中，DLL 链接模型意味着已经考虑了间接依赖关系。
我们不希望必须明确指定完全扩展的依赖项列表，因为这过于冗长并且存在维护问题。
目前的系统仍然有缺陷，它确实要求我们只需要在包 SConscripts 中指定直接依赖关系，但通过 SConstruct 中的 Python 代码解决间接依赖关系。此代码打开并解析 SConscript 文件，并根据提取的信息构建依赖关系图。这种方法感觉不对。直觉上，我觉得应该有一种方法可以使用本地 SCons 设施更自然地做到这一点，但我对 SCons 不够熟悉，无法提出更好的方法。有没有更好的方法，是什么？
【问题讨论】：
-
你检查过例如的输出吗？
scons --tree=derived? -
如果我理解正确的话，那是 scons 的调试工具。我不确定它将如何帮助解决这个问题。如果我遗漏了什么，请告诉我。