我曾经参与过一个 C++ 项目，需要大约一个半小时才能完全重建。小型编辑、构建、测试周期大约需要 5 到 10 分钟。这是一场徒劳的噩梦。
您曾经经历过的最糟糕的构建时间是什么？
您使用了哪些策略来缩短大型项目的构建时间？
更新：
您认为所使用的语言在多大程度上是造成问题的原因？我认为 C++ 容易对大型项目产生大量依赖，这通常意味着即使是对源代码的简单更改也可能导致大规模重建。您认为哪种语言最能解决大型项目的依赖问题？
【问题讨论】：
标签： c++ compiler-construction build-process build-automation
[稍后编辑] 8. 购买速度更快的机器。
【讨论】：
我的策略很简单——我不做大型项目。现代计算的整个推动力是从巨大的和单一的转向小型的和组件化的。因此，当我处理项目时，我会将事物分解为可以独立构建和测试的库和其他组件，并且它们之间的依赖关系最小。在这种环境中“完整构建”实际上从未发生过，因此没有问题。
【讨论】：
有时会有帮助的一个技巧是将所有内容都包含在一个 .cpp 文件中。由于每个文件处理一次包含，因此可以节省大量时间。 （这样做的缺点是编译器无法并行编译）
您应该能够指定应该并行编译多个 .cpp 文件（Linux 上使用 make 的 -j，MSVC 上使用 /MP - MSVC 还具有并行编译多个项目的选项。这些是单独的选项，并且没有理由你不应该同时使用两者）
同样，分布式构建（例如 Incredibuild）可能有助于减轻单个系统的负载。
SSD 磁盘应该是一个巨大的胜利，虽然我自己还没有测试过（但是 C++ 构建涉及大量文件，这很快就会成为瓶颈）。
谨慎使用时，预编译的头文件也有帮助。 （如果它们必须经常重新编译，它们也会伤害你）。
最后，尽量减少代码本身的依赖关系很重要。使用 pImpl 习惯用法，使用前向声明，尽可能保持代码模块化。在某些情况下，使用模板可以帮助您解耦类并最小化依赖关系。 （当然，在其他情况下，模板会显着减慢编译速度）
但是，是的，你是对的，这在很大程度上是一个语言问题。我不知道另一种语言会受到这种程度的影响。大多数语言都有一个模块系统，允许它们消除头文件，这是一个巨大的因素。 C 有头文件，但它是一种如此简单的语言，编译时间仍然可以管理。 C++ 是两全其美的。一种庞大的复杂语言，以及一种可怕的原始构建机制，需要一次又一次地解析大量代码。
【讨论】：
#include 所有内容放入一个通用 cpp 文件中，然后构建它。这不会给你 17000 行长的文件。它仍然有它的缺点（主要是它阻止了增量重建），但这是一个值得一提的技巧。
最后两个使我们的链接时间从大约 12 分钟减少到 1-2 分钟。请注意，仅当事物具有巨大的可见性时才需要这样做，即“无处不在”并且存在许多不同的常量和类。
干杯
【讨论】：
【讨论】：
统一构建
Incredibuild
指向实现的指针
前向声明
将项目的“已完成”部分编译到 dll 中
【讨论】：
ccache 和 distcc（用于 C/C++ 项目）-
ccache 缓存编译后的输出，使用预处理文件作为查找输出的“键”。这很好，因为预处理非常快，而且强制重新编译的更改通常不会真正更改许多文件的源。此外，它确实加快了完全重新编译的速度。同样不错的是您可以在团队成员之间共享缓存的实例。这意味着只有第一个获取最新代码的人才能真正编译任何东西。
distcc 在机器网络上进行分布式编译。仅当您有用于编译的机器网络时，这才有用。它与 ccache 配合得很好，并且只会移动预处理的源代码，因此您在编译器引擎系统上唯一需要担心的是它们具有正确的编译器（不需要标题或整个源代码树可见)。
【讨论】：
最好的建议是构建真正理解依赖关系的 makefile，并且不会为了一个小的变化而自动重建世界。但是，如果完全重建需要 90 分钟，而小型重建需要 5-10 分钟，那么很有可能您的构建系统已经这样做了。
构建可以并行完成吗？多核还是多服务器？
为真正静态且不需要每次都重新构建的片段检查预编译位。使用但未更改的第 3 方工具/库是此处理的良好候选者。
如果适用，将构建限制为单个“流”。 “完整产品”可能包括调试版本或 32 位和 64 位版本，或者可能包括每次派生/构建的帮助文件或手册页。删除开发不需要的组件可以显着减少构建时间。
构建是否还打包产品？这真的需要开发和测试吗？该构建是否包含一些可以跳过的基本健全性测试？
最后，您可以重构代码库，使其更加模块化并减少依赖项。 Large Scale C++ Software Design 是学习将大型软件产品解耦为更易于维护和更快构建的东西的绝佳参考。
编辑：在本地文件系统上构建而不是在 NFS 挂载的文件系统上也可以显着加快构建时间。
【讨论】：
【讨论】：
这本书Large-Scale C++ Software Design 有非常好的建议，我在过去的项目中使用过。
【讨论】：
【讨论】：
强大的编译器和并行编译器。我们还确保尽可能少地需要完整构建。我们不会更改代码以使其编译速度更快。
效率和正确性比编译速度更重要。
【讨论】：
在 Visual Studio 中，您可以设置一次编译的项目数量。它的默认值为 2，增加它会减少一些时间。
如果您不想弄乱代码，这将有所帮助。
【讨论】：
这是我们在 Linux 下为开发所做的事情清单：
【讨论】：
我们曾经尝试过创建代理类。
这些确实是一个类的简化版本，只包含公共接口，减少了需要在头文件中公开的内部依赖项的数量。然而，他们付出了沉重的代价，将每个类分散到多个文件中，当对类接口进行更改时，所有这些文件都需要更新。
【讨论】：
一般来说，我从事的大型 C++ 项目的构建时间很慢，非常混乱，代码中散布着许多相互依赖关系（大多数 cpps 中使用的相同包含文件，胖接口而不是瘦接口）。在这些情况下，缓慢的构建时间只是较大问题的症状，也是次要症状。重构以使接口更清晰，并将代码分解为库，从而改善了架构和构建时间。当您创建一个库时，它会迫使您考虑什么是接口，什么不是，这实际上（根据我的经验）最终会改进代码库。如果没有技术原因需要划分代码，一些程序员在维护过程中只会将任何内容放入任何头文件中。
【讨论】：
Cătălin Pitiş 介绍了很多好东西。我们做的其他事情：
【讨论】：
这是我的一个小烦恼，所以即使你已经接受了一个很好的答案，我也会插话：
在 C++ 中，与其说是语言本身，不如说是 70 年代的语言强制构建模型，以及头文件繁重的库。
Cătălin Pitiş 的回复唯一有问题的地方是：“购买更快的机器”应该放在首位。这是最简单、影响最小的方法。
在 W2K Professional 上运行 VC6 的老化构建机器上，我最糟糕的是大约 80 分钟。现在，在具有 4 个超线程内核、8G RAM Win 7 x64 和不错的磁盘的机器上，相同的项目（包含大量新代码）只需不到 6 分钟。 （类似的机器，处理器功率减少约 10..20%，配备 4G RAM 和 Vista x86 需要两倍的时间）
奇怪的是，增量构建现在大部分时间都比完全重建慢。
【讨论】：
完整构建大约需要 2 小时。我尽量避免对基类进行修改，因为我的工作主要是实现这些基类，所以我只需要构建小组件（几分钟）。
【讨论】：
创建一些单元测试项目来测试各个库，这样如果您需要编辑会导致大量重建的低级类，您可以在重建整个应用程序之前使用 TDD 来了解您的新代码是否有效。 Themis 提到的 John Lakos 书中提供了一些非常实用的建议，可帮助您重组图书馆以实现这一目标。
【讨论】：