4

我是 scons 的新手，并试图移植现有的 Visual Studio 解决方案（.sln），该解决方案在内部引用了许多 VS 项目文件（.vcxproj）。这是多个输出，包括各种库和不同的可执行文件。

从概念的角度来看，我不确定我是否走在正确的道路上，并且会感谢任何关于如何做得更好的建议。

这是我的设置：

我在代码仓库的根目录中有一个顶级 SConstruct 文件。此外，我的每个旧 VS 项目文件都有一个 SConscript 文件。SConstruct 文件为这些 SConscript 文件中的每一个调用 SConscript 函数一次，它在其中指定源目录以及输出应作为参数的位置。

此外，SConstruct 文件创建并向每个 SConstruct 文件传递​​一个 scons 环境实例数组。例如，有一个用于编译库，一个用于编译可执行文件，一个用于调试配置，一个用于发布等，然后每个 SConscript 文件根据它要完成的任务选择它想要的一个。

有几件事我想知道：1）有没有比创建多个不同环境更好的方法，每个配置变体一个？这是预期的使用模式吗？2）在Visual Studio中，我可以右键单击特定项目并选择构建以仅构建该项目及其所依赖的项目，而忽略sln中的其余依赖关系图。使用 scons，它是否会在每次触发特定库的构建时重新计算整个依赖关系图，即使理论上它只需要计算整个依赖关系图的一小部分。

感谢您的任何建议。

标记

4

1 回答 1

0

您让 SConstruct 调用多个附属 SConscript 文件的方法确实是组织项目的好方法，称为Hierarchical SCons build。

关于你的问题，这里有一些事情需要考虑：

  1. 几种不同的环境：除非您对每个构建器或目标（库、可执行文件等）有不同的编译器或编译器标志，否则我会说您使用的方法有点矫枉过正。您很可能只使用一种环境就可以达到同样的效果。如果您确实需要每个子目录/构建器的附加标志，那么您可以考虑将“主”环境传递给子目录，并在相应的 SConscript 中克隆 env 并添加/附加您需要的内容，如此处所述。这样，整个解决方案将更加模块化，避免重复并将所有通用的东西放在一个中心位置。

  2. 构建某些项目/目标：您可以通过在命令行上选择目标来对 SCons 执行相同的操作，如下所示$ scons yourTarget。您可以使用env.Alias()函数使目标名称更易于管理。SCons 确实在构建之前分析了所有内容，但是根据项目的大小，这应该不是问题，它仍然很快。如果构建性能确实成为问题，这里有一些改进性能的建议。

这里有一些额外的好东西要知道：

于 2012-05-27T10:47:09.970 回答