SCons 设置为分层源但单一目标

发布于 2024-12-26 01:58:30 字数 701 浏览 0 评论 0原文

我有一个一直在开发的 C++/Python 项目，到目前为止一直依赖 Visual Studio 来管理构建。现在我想自动化构建过程，希望包括多个平台支持（都是标准 C++/Python），并认为 SCons 可以成为完成这项工作的工具。

涉及到很多源文件，位于多个目录中，但（立体）典型示例如下：

foo.lib
  directory_1
    bar1_1.cpp
    bar1_2.cpp
    ... etc. ...
  directory_2
    bar2_1.cpp
    bar2_2.cpp
    ... etc. ...

因此，换句话说，源文件位于层次结构中，但只有一个目标。（层次结构与代码中使用的命名空间相匹配，但这对于这个问题来说是多余的。）

我的问题是：构建 SConstruct 和 SConscript 文件的最佳方法是什么？我阅读了 SCons 文档，特别是“分层构建”部分以及使用多个 SConscript 文件和合适的“SConscript”调用的想法。一切看起来都很清晰，而且特别整洁。然而，这似乎适用于具有多个目标的层次结构。我可以在只有一个目标的情况下使用这一相同的功能吗？

（我确实想到了一个顶级 SConstruct/SConscript 文件，至少对于有问题的库来说，列出了带有子目录的所有源文件，但“感觉”不是最好的方法。也许这确实是前进的方向？）

提前非常感谢您的任何建议/见解。

原文

I have a C++/Python project that I've been working on and so far have relied on Visual Studio to manage the builds. Now I want to automate the build process, hopefully include multiple platform support (it's all standard C++/Python), and think SCons could be the tool to do the job.

There's a lot of source files involved, in multiple directories, but a (stereo)typical example is as follows:

foo.lib
  directory_1
    bar1_1.cpp
    bar1_2.cpp
    ... etc. ...
  directory_2
    bar2_1.cpp
    bar2_2.cpp
    ... etc. ...

So, in other words, the source files are in a hierarchy, but there's only a single target. (The hierarchy is matched in the namespaces used in the code, but this is superfluous for purposes of this question.)

My question is: What's the best way to structure the SConstruct and SConscript files? I read the SCons documentation, particularly, the Hierarchical Builds section and the idea to use multiple SConscript files with suitable 'SConscript' calls. All seems clear, and particularly neat. However it would seem this is intended for a hierarchy with multiple targets. Can I use this same feature where there's only one target?

(I did think of a top level SConstruct/SConscript file, at least for the library in question, listing all the source file with subdirectories, but doesn't "feel" the best way to do it. Maybe indeed this is the way forward?)

Many thanks in advance for any advice / insight.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

人生百味 2025-01-02 01:58:30

我曾多次使用类似于您所描述的分层解决方案。我选择了这样的解决方案：

在 SConscript:

#/bar/SConscript
Import("env")
env = specialize_env_for_this_subpackage()

myfiles = Glob(*.cpp)
apply_any_exclusions(myfiles)
myobjects = env.Object(myfiles)

Return(myobjects)

然后在 SConstruct:

#SConstruct
env = construct_general_environment()

subpackages = ["foo","bar","baz"] #or perhaps call your own find_subproject() function

objects = SCons.Node.NodeList
for package in subpackages:
    pack_objects = env.SConscript(os.path.join(package,"SConscript"), exports = env)
    objects.extend(pack_objects)
program = env.Program("myprog",objects)

Default(program)

然后你可以对每个包中的环境进行微调控制，并且通过巧妙地使用 *site_scons* 文件夹，你可以防止一遍又一遍地重复相同的行对于每个新兵。这种方法的另一个优点是 scons 文件反映了设计。我还更喜欢使用 Glob 来收集 cpp 文件，这样我就可以根据需要添加和删除文件，而无需为此类琐碎的操作编辑任何构建文件。

I have several times used a hierarchical solution much like the one you describe. I have chosen a solution like this:

in the SConscript:

#/bar/SConscript
Import("env")
env = specialize_env_for_this_subpackage()

myfiles = Glob(*.cpp)
apply_any_exclusions(myfiles)
myobjects = env.Object(myfiles)

Return(myobjects)

then in the SConstruct:

#SConstruct
env = construct_general_environment()

subpackages = ["foo","bar","baz"] #or perhaps call your own find_subproject() function

objects = SCons.Node.NodeList
for package in subpackages:
    pack_objects = env.SConscript(os.path.join(package,"SConscript"), exports = env)
    objects.extend(pack_objects)
program = env.Program("myprog",objects)

Default(program)

Then you have fine tuned control over the environment in each package, and with clever use of the *site_scons* folder you can prevent repeating the same lines over and over for each sconscript. Another advantage with this approach is that the scons files reflects the design. I also prefer using a Glob to gather cpp files, allowing me to add and remove files as I like, without editing any build files for such trivial operations.

回复收藏 0 原文

不美如何 2025-01-02 01:58:30

在一个 SConstruct 文件中列出所有源文件并没有什么问题。分层结构 SConscripts 也很好，但您需要从每一层返回对象，这会有点愚蠢：

# SConscript, for example
sources = ["bar1_1.cpp", "bar1_2.cpp", ...]
objects = [env.Object(x) for x in sources]
Return(objects)

# SConstruct (top-level)
directory_1_objects = SConscript("directory_1/SConscript")
directory_2_objects = SConscript("directory_2/SConscript")
program = env.Program("magical_wonders", [directory_1_objects, directory_2_objects])

在我看来，特定二进制文件中所有源文件的单个顶级栅格比这更好，当文件层次结构发生变化时，这需要更多的接线。

There is nothing wrong with listing all the source files in one SConstruct file. Hierarchically structuring SConscripts is also fine, but you will need to return objects from each layer, which will get a little silly:

# SConscript, for example
sources = ["bar1_1.cpp", "bar1_2.cpp", ...]
objects = [env.Object(x) for x in sources]
Return(objects)

# SConstruct (top-level)
directory_1_objects = SConscript("directory_1/SConscript")
directory_2_objects = SConscript("directory_2/SConscript")
program = env.Program("magical_wonders", [directory_1_objects, directory_2_objects])

In my own opinion, a single top-level raster of all the source files in a particular binary is preferable to this, which requires more wiring when the file hierarchy changes.

回复收藏 0 原文

~没有更多了~