Build 将visual studio解决方案文件移植到SCON的最佳实践

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

从概念的角度来看，我不确定自己是否走上了正确的道路，如果有任何关于如何做得更好的建议，我将不胜感激

以下是我的设置：

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

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

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

谢谢你的建议

---

标记

让一个SConstruct调用几个子SConscript文件的方法确实是组织项目的一种好方法，称为SConstruct

关于您的问题，以下是一些需要考虑的事项：

几种不同的环境：除非每个构建器或目标（库、可执行文件等）有不同的编译器或编译器标志，否则我认为您使用的方法有点过分。您很可能只需要一个环境就可以实现同样的效果。如果你确实需要每个子目录/生成器附加标志，那么你可以考虑将“主”环境传递给子目录，在相应的SCONScript中，克隆Env并添加/追加你所需要的。通过这种方式，整个解决方案将更加模块化，避免重复，并将所有公共内容保持在一个中心位置

构建某些项目/目标：通过在命令行上选择目标，您可以对SCON执行相同的操作，如下

$SCons yourTarget

。您可以使用该函数使目标名称更易于管理。SCons确实在建造之前分析了所有的东西，但是根据项目的规模，这不应该是一个问题，它仍然相当快。如果构建性能确实成为一个问题，那么下面是一些改进性能的指针

这里有一些额外的好事情要知道：

• 与其他开源工具相比，WRT还不错。在文档页面的底部，有几个附录，其中有很多额外的信息。这本书也很完整
• 如果您没有使用前面提到的“#”，则SCON中的路径可能会混淆
• 如果需要处理MSVS项目，可以使用前面提到的MSVSProject（）和MSVSSolution（）编译程序

---

谢谢你，布雷迪。我看到的大多数示例似乎也支持单环境方法。我可以看出多环境方法可能会很快失控。