【问题标题】:Best practices for porting a visual studio solution file to scons将 Visual Studio 解决方案文件移植到 scons 的最佳实践
【发布时间】:2012-06-02 00:01:29
【问题描述】:

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

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

这是我的设置:

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

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

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

感谢您的建议。

标记

【问题讨论】:

    标签: build scons


    【解决方案1】:

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

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

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

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

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

    • SCons documentation 对其他开源工具来说是不错的 WRT。在该文档页面的底部,有几个包含大量额外信息的附录。 SCons man page 也很完整。
    • 如果您不使用提到的“#”here,SCons 中的路径可能会令人困惑
    • 如果您需要处理 MSVS 项目,可以使用 here 中提到的 MSVSProject() 和 MSVSSolution() 构建器。

    【讨论】:

    • 谢谢布雷迪。我见过的大多数例子似乎也提倡单一环境方法。我可以看到多环境方法可能会如何迅速失控。
    猜你喜欢
    • 1970-01-01
    • 2011-04-08
    • 1970-01-01
    • 2011-12-31
    • 1970-01-01
    • 1970-01-01
    • 2015-12-19
    • 2015-11-28
    • 2010-10-16
    相关资源
    最近更新 更多