c++ - 使用 Unity Builds 加速 C++ 构建并减少头文件依赖

Question

我刚刚将一个 Objective-C(++) 项目转换为纯 C++。在移动越来越多的代码时，我注意到构建时间增加了很多。

我的项目目前分为几个框架/dylibs 和一个使用这些框架的主项目。

我做了一些研究，发现基本上推荐了三件事来减少构建时间：

我实现了 ccache，它工作得很好，我能够大大减少构建时间。

我有点不确定是否要减少头文件依赖和统一构建。我读到统一构建的一大缺点是，如果您对一个有意义的源文件进行更改，则需要重新编译所有内容。然而，这对框架来说不是问题，因为如果它们发生变化，无论如何都需要重新编译它们。

我读到使用“伞形头文件”（例如“MyFramework.h”）是一种不好的做法，它将包含给定框架的所有公共头文件，尽管您可能只需要其中的几个。

Cocoa 在任何地方都使用伞头文件，这当然比为每个源文件挑选所需的确切标题要容易得多。但是，当使用统一构建时，每个框架只有一个标头，对吗？

选择单个标题是否仍然有意义，或者在统一构建中使用“伞形标题”是否可以？

在这里摸摸摸摸，不想花时间实施最终无济于事的技术。

谢谢你的帮助！

score -1 · Accepted Answer

感觉就像是对自以为是的答案提出的问题。我的是这样的：

始终减少标头依赖性。减少的依赖使整体架构更干净。具有明确职责、松散耦合的独立小独立模块总是比意大利面条更好用。

使用预编译的头文件来编译很少更改的头文件。第三方、库和框架伞头文件很少更改，因此也很少需要解析和重新编译。

大部分时间使用单独的单元（很少的 cpp 文件）和单元测试。否则，您构建整个程序，然后在其中导航到感兴趣的情况，然后在那里使用调试器等等。可能是你喜欢，但我太懒了，重复无聊，浪费我的时间。仅链接整个 C++ 程序（值得任何东西）通常需要十分钟或更长时间，而且我不需要这么多的咖啡休息时间。

不要使用统一构建，最好使用持续集成，当您推送时自动构建和运行整个程序的所有单元测试并在其他计算机（或农场）上准备二进制文件。当它完成（或失败）时，您会收到通知，然后如果您愿意，您也可以获取二进制文件并调试整个程序。

1 回答 1