2

我在这里浏览了示例 scons 构建，发现他们想要提供适合我项目的解决方案。

结构如下：

root/
   Module_A/
      include/
         foo.h
         bar.h
      src/
         foo.cpp
         bar.cpp
   Module_.../

每个模块都遵循相同的结构，所有 .h 的包含文件夹和 cpps 的 src 文件。每个模块都构建成一个共享对象。没有可执行文件。

模块具有交叉依赖关系。例如 Module_A 是日志机制，它用于模块 B、C、D 等。同样，Module_B 是配置加载器，用于其他几个模块。Module_C 将是 IPC 模块，几乎用于列出的每个模块。最后，Module_D 是命令中心，并链接到所有其他模块（字面意思）。

我有兴趣替换我们使用递归 make 来构建项目的当前设置。我正在尝试构建必要的 sconstruct 和 SConscripts，但我什至还很陌生，更不用说 scons 了。

我有兴趣将每个模块的 .cpp 和 .h 转换为 .so并像现在使用 make 一样自动解决其依赖关系。

在 SConscript 中，我目前使用 glob 获取 *.cpps，然后将模块的“./include”包含在 CPPPATH 中。我用过

env.SharedLibrary(CPPATH='./include', source= (list of the cpps))

但是由于这依赖于其他模块，所以它不起作用，说明使用的其他模块的功能是“未声明的”。

如何使用分层 scons 设置构建这种复杂的结构？

4

1 回答 1

5

使用 SCons 应该很容易做到这一点。您可能希望在每个模块的根目录中都有一个 SConscript 脚本。这些都将由位于整个项目根目录的 SConstruct 脚本调用。

如果我正确理解了这个问题，则可以通过正确指定所有模块的包含路径来解决模块之间的依赖关系问题。这可以在 SConstruct 中创建的环境中完成一次，然后应将其传递给模块 SConscript 脚本。

这是一个简短的例子：

构造

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)

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)

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)

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)
于 2013-01-18T11:28:20.730 回答