我已经完成了这里的scons构建示例,发现他们希望提供适合我项目的解决方案.
结构如下:
root/
Module_A/
include/
foo.h
bar.h
src/
foo.cpp
bar.cpp
Module_.../
Run Code Online (Sandbox Code Playgroud)
每个模块都遵循相同的结构,包括所有.h的include文件夹和cpps的src文件.每个模块构建为共享对象.没有可执行文件.
模块具有交叉依赖性.例如,Module_A是日志记录机制,它用于模块B,C,D等.同样,Module_B是配置加载程序,在其他几个模块中使用.Module_C将是IPC模块,几乎用于列出的每个模块.最后,Module_D是命令中心,并链接到每个其他模块(字面意思).
我有兴趣替换我们使用递归make来构建项目的当前设置.我正在尝试构建必要的sconstruct和SConscripts,但我甚至很新,甚至是scons.
我有兴趣将每个Module的.cpp和.h转换为.so并使其依赖关系自动解决,就像make now一样.
在SConscript中,我目前使用glob来获取*.cpps,然后在CPPPATH中包含模块的'./include'.我用过
env.SharedLibrary(CPPATH='./include', source= (list of the cpps))
但由于这取决于其他模块,它将无法工作,说明使用的其他模块的功能是"未声明".
如何使用分层scons设置来构建这种复杂的结构?
这对SCons来说应该很容易.您可能希望在每个模块的根目录下使用SConscript脚本.这些都将由位于整个项目根目录的SConstruct脚本调用.
如果我正确理解了这个问题,可以通过正确指定所有模块的包含路径来解决模块之间依赖关系的问题.这可以在SConstruct中创建的环境中完成一次,然后应该将其传递给模块SConscript脚本.
这是一个简短的例子:
Sconstruct
env = Environment()
# Notice that the '#' in paths makes the path relative to the root SConstruct
includePaths = [
'#/Module_A/include',
'#/Module_B/include',
'#/Module_N/include',
]
env.Append(CPPPATH=includePaths)
SConscript('Module_A/SConscript', exports='env', duplicate=0)
SConscript('Module_B/SConscript', exports='env', duplicate=0)
SConscript('Module_N/SConscript', exports='env', duplicate=0)
Run Code Online (Sandbox Code Playgroud)
Module_A/SConscript
Import('env')
# Notice the CPPPATH's have already been set on the env created in the SConstruct
env.SharedLibrary(target = 'moduleA', source = ModuleA_SourceFiles)
Run Code Online (Sandbox Code Playgroud)
Module_B/SConscript
Import('env')
# Notice the CPPPATH's have already been set on the env created in the SConstruct
env.SharedLibrary(target = 'moduleB', source = ModuleB_SourceFiles)
Run Code Online (Sandbox Code Playgroud)
Module_N/SConscript
Import('env')
# Notice the CPPPATH's have already been set on the env created in the SConstruct
env.SharedLibrary(target = 'moduleN', source = ModuleN_SourceFiles)
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
452 次 |
| 最近记录: |