我是scons的新手，并尝试移植现有的Visual Studio解决方案（.sln），该解决方案在内部引用了许多VS项目文件（.vcxproj）。这是多个输出，包括各种库和不同的可执行文件。
从概念的角度来看，我不确定自己是否走上了正确的道路，并希望了解如何做得更好。
这是我的设置：
我在代码库的根目录下有一个顶级SConstruct文件。另外，我为每个旧的VS项目文件都有一个SConscript文件。 SConstruct文件为每个SConscript文件调用SConscript函数一次，其中它指定源目录以及输出应作为参数的位置。
此外，SConstruct文件创建并向每个SConstruct文件传递一个scons环境实例数组。例如，有一个用于编译库，一个用于编译可执行文件，一个用于调试配置，一个用于发布等，然后每个SConscript文件根据它想要完成的内容选择它想要的那个。
有几件事我想知道： 1）是否有比创建多个不同环境更好的方法，每个配置变体一个？这是预期的使用模式吗？ 2）在visual studio中，我可以右键单击特定项目并选择构建以仅构建该项目及其所依赖的项目，而忽略sln中的其余依赖图。使用scons，每次触发特定库的构建时，它都会重新计算整个依赖图，即使理论上它只需要计算整个依赖图的一小部分。
感谢您的任何建议。
标记
答案 0 :(得分：0)
让SConstruct调用几个辅助SConscript文件的方法确实是组织项目的好方法，称为Hierarchical SCons build。
关于您的问题，以下是需要考虑的事项：
几种不同的环境：除非每个构建器或目标（库，可执行文件等）都有不同的编译器或编译器标志，否则我会说你使用的方法有点矫枉过正。你很可能只用一个环境就可以达到同样的效果。如果你确实需要为每个子目录/构建器添加额外的标志，那么你可以考虑将“main”环境传递给子目录，并在相应的SConscript中，克隆env并添加/追加你所需要的内容here 。通过这种方式，整个解决方案将更加模块化，避免重复并将所有内容保持在一个中心位置。
构建某些项目/目标：您可以通过在命令行上选择目标来对SCons执行相同的操作，例如$ scons yourTarget。您可以使用env.Alias()函数使目标名称更易于管理。 SCons确实在构建之前分析了所有内容，但根据项目的大小，它不应该是一个问题，它仍然非常快。如果构建性能确实成为问题，here是提高性能的一些指示。
以下是一些额外的好事：