【发布时间】:2018-10-13 04:03:28
【问题描述】:
我遇到了以下问题: 我们有一个大型项目(继承自其他公司)编译了许多SW的子m子。FW的构建分为几个SConscripts 我们从主 SConstruct 调用。关键是所有子模块共享相同的编译标志和 定义。
我打算用以下解决方案来解决这个问题:
在主入口点,SConstruct我们定义了某些编译选项:
COMPILER_FLAGS = '-g \ -O3 \ -fshort-双\ -gdwarf-2\ -墙 \ -W\ -Werror-隐式函数声明\ -Wno-未使用的变量\ -Wno-empty-body \ -Wbad-function-cast \ -Wstrict-原型\ -Wmissing-noreturn \ -Wnested-externs \ -fno 内置 \ -Wno-未使用的参数\ -Wno-pointer-to-int-cast \ ..........
这个 COMPILER_FLAGS 是作为参数传递给每个 Sconscript 的构造环境 然后在每个 Sconscript 中,我克隆环境并修改每个子模块的一些选项
*S构造
log_path = os.path.join('../../CDD/LogPrint/Build/logprint.SC')
objects += SConscript(log_path, exports='env', variant_dir=log_build_dir, duplicate=1)
dbg_exe = env.Program(dbg_path, objects)
*logprint.SC
\#Customize Compilation options for this component
own_env = env.Clone()
own_env['COMPILER_FLAGS'] += '-O0 '
\# COMPILE SOURCE FILES
objects += own_env.Library(sources)
\# RETURN
Return('objects')
关键是当我为 logprint 子模块编译(并构建一个库)时,我没有看到 own_env 扩展 编译的标志。我仍然在编译命令行中看到打印了从主 SConstruct 文件继承的初始 env 选项。
为什么会发生这种情况?是否有任何顶级 SCONS 选项/配置设置此行为? 让我还强调一下,我从头开始在一个新的小项目中探索了 env.Clone 的这个概念,并在那里 作品。所以我想知道一些顶级 SCONS 配置可能会阻止我在“大”中想要的 own_env.Library 行为 项目。
【问题讨论】:
-
您可以在分配给
$COMPILER_FLAGS之前和之后使用print env.Dump()和print own_env.Dump()来检查分配是否正确工作。但是,即使$COMPILER_FLAGS设置正确,如果我们正在讨论编译 C 或 C++ 源代码,这些标志也不会在编译期间被拾取。您必须遵守标准的 SCons 约定并改用$CCFLAGS或$CXXFLAGS。请查看SCons UserGuide 了解更多信息,尤其是列出所有标准构造变量的附录 A。 -
COMPILER_FLAGS 对任何默认构建器都没有影响。您的示例代码也不完整。您能否充实您的 SConstruct 和 SConscript 以便我们尝试运行它?
标签: scons