【发布时间】:2017-06-26 15:49:29
【问题描述】:
我的 SCons 项目依赖于很多第三方库,每个库都提供了数十或数百个包含文件。
我对 SCons 工作原理的理解是,在每次构建时,它都会解析我的项目的源文件以查找 #include 指令,并使用 env['CPPPATH'] 的值来查找这些文件并计算它们的 md5 和.
这种扫描成本很高,因此我想通过教导 SCons 我的第三方文件的所有标题永远不会改变来优化这个过程。这个属性实际上是由管理我们第三方库的工具强制执行的。
我知道有一个--implicit-deps-unchanged 选项强制 scons 假设隐式依赖项没有改变,但它在全局范围内有效。我没有找到将此选项限制为特定目录的方法。我试图查找是否可以配置隐式C++文件的默认Scanner,但什么也没找到。我认为可以避免使用CPPPATH,而是直接给编译器提供-I选项,但是比较麻烦。
有没有什么方法可以优化 SCons,让他知道目录中的文件永远不会改变?
【问题讨论】:
-
您能否详细介绍一下您如何分析构建过程以确保扫描标头是大问题?您是否尝试重新排列包含路径的顺序,以便在第一次尝试时直接找到大多数头文件?除此之外,除了编写您自己的自定义 C/CPP 扫描器之外,我认为优化的潜力不大......
-
@dirkbaechle “您能多谈谈您是如何分析构建过程的 [...]”。我知道在最新版本中添加参数
--max-drift=1 --implicit-deps-unchanged(即不计算任何文件的 md5)会使我的项目的执行时间从 59 秒下降到 13 秒。此外,我们依赖于大约 30 个第三方库,包括标题繁重的 Boost。 -
Boost 应该首先列在
CPPPATH然后。 ;) 您可能希望使用--debug=time选项检查阅读 SConscripts 与实际建筑的时间。如果您今天非常喜欢冒险,请尝试my fastcpp Tool...但请注意免责声明页面。 -
我现在可以分享一些数字。我实现了这两种解决方案:一切都在
CPPPATH中的简单解决方案,以及我的第三方包含的解决方案是使用CCFLAGS中的-I选项指定的。 noop 构建的 SConc 执行时间对于 naive 解决方案需要 168 秒,对于CCFLAGS解决方案需要 35 秒。
标签: scons