超级简单,完全无聊的设置:我有一个充满 .hpp 和 .cpp 文件的目录。其中一些 .cpp 文件需要内置到可执行文件中;当然,这些.cpp文件#include一些.hpp文件在同一目录下,然后可能包含其他的等等等等。那些.hpp文件大部分都有对应的.cpp文件,也就是说:如果some_application.cpp #includes foo.hpp,无论是直接的还是传递的,那么很可能还有一个 foo.cpp 文件需要编译并链接到 some_application 可执行文件中。
超级简单,但我仍然不知道在 SCons 或 CMake 中构建它的“最佳”方式是什么(除了盯着最后一天左右的文档外,我还没有任何专业知识)变得悲伤)。我担心在大多数构建系统中我想要的那种解决方案实际上可能是不可能的(或者至少过于复杂),但如果是这样,很高兴知道这一点,这样我就可以放弃并且不那么挑剔了. 自然,我希望我是错的,考虑到我对构建系统的无知(通常,特别是关于 CMake 和 SCons),这并不奇怪。
当然,CMake 和 SCons 都可以自动检测到 some_application.cpp 依赖的任何头文件(直接或传递)发生变化时需要重新编译,因为它们可以很好地“解析”C++ 文件以挑选出那些依赖关系。好的,太好了:我们不必手动列出每个 .cpp-#includes-.hpp 依赖项。但是:我们仍然需要决定在实际生成每个可执行文件时需要将哪些目标文件子集发送到链接器。
据我了解,处理这部分问题的两个最直接的选择是:
- A. 手动明确且费力地枚举“使用此目标文件的任何内容也需要使用这些其他目标文件”依赖项,即使这些依赖项完全由对应的-.cpp-transitively-includes-the-corresponding-.hpp 镜像构建系统已经为我们解决了麻烦。为什么?因为电脑。
- B. 将该目录中的所有目标文件转储到一个“库”中,然后让所有可执行文件依赖并链接到该库中。这要简单得多,我理解大多数人都会这样做,但这也有点草率。大多数可执行文件实际上并不需要该库中的所有内容,如果仅更改一两个 .cpp 文件的内容,则实际上不需要重新构建。这不正是建立所谓的“构建系统”应该避免的那种不必要的计算吗?(我想如果库是动态链接的,也许它们不需要重建,但我只想说我不喜欢动态链接的库是出于其他原因。)
CMake 或 SCons 能以任何远程直接的方式做得比这更好吗?我看到了一堆有限的方法来旋转自动生成的依赖图,但没有通用的方法可以交互地这样做(“好的,构建系统,你认为依赖关系是什么?啊。好吧,在此基础上,添加遵循依赖关系并再想一想:...”)。我也不是对此感到惊讶。不过,我还没有在任何一个构建系统中找到一种特殊用途的机制来处理链接时依赖项应该反映相应的编译时#include 依赖项的超级常见情况。我是否在阅读文档时遗漏了某些内容(诚然有些粗略),或者每个人都只是选择选项(B)并默默地讨厌自己和/或他们的构建系统?