1

我正在做一个即将变得更大的大型项目。在此之前，我想解决的问题之一是构建速度。

过去我们使用 Single Compilation Unit / Unity Builds 来大大提高构建速度。详细信息可以在这里找到http://buffered.io/posts/the-magic-of-unity-builds/

本质上，您创建一个包含多个 #include other.cpp 的 .cpp 文件

例如 scu.cpp 的内容

#include apple.cpp
#include banana.cpp
#include cherry.cpp

......

它创建了一个 scu.obj。这降低了构建速度，因为它减少了文件 I/O。

但是也有缺点

  • .cpp 中的全局变量/函数是共享的，可能会发生冲突
  • 开发人员可以忘记在 .cpp 中#include 文件并摆脱它

另一个坏事是，开发人员可能需要手动维护 scu.cpp（但这对我们来说将是自动化的，所以这不是问题）。

由于这些缺点，我们离开了 SCU。但我很想把它带回来，因为构建速度的提高真的很诱人（减少 50 - 75%）。

有没有办法避免这些冲突？我测试过

scu.cpp 的内容

namespace unique_1 {
#include apple.cpp
}
namespace unique_2 {
#include banana.cpp
}
namespace unique_3 {
#include cherry.cpp
}

但这只会产生错误

error C3083: 'vc_attributes': the symbol to the left of a '::' must be a type
........

它源于命名空间内的#include。

有替代方案吗？还有其他解决方案吗？

该线程建议不（不幸的是）

安全的 Unity 构建

单独构建来测试非 SCU 解决方案很容易实现。但在我们的组织内部却不受欢迎。IE

  • 全局变量/函数有效（在 c++ 教科书中）
  • 可能会在没有意识到的情况下破坏 SCU/非 SCU（直到发生构建破坏）
4

0 回答 0