这个构建系统可以加速吗？

Question

我们的构建速度很慢。它在 linux 上使用嵌套的 gnu makefile。它为来自同一源树的三个不同目标创建三个构建。它使用符号链接依次指向三个并行目录树中的每一个。我们可以通过在子目录中使用 make 来进行部分构建，这样可以节省时间，但如果我们的工作跨越多个目录，我们必须为三个目标中的至少一个进行构建，这至少需要 45 分钟。仅构建子目录可能需要“仅”5-10 分钟。

您知道哪些快速检查可能会导致此构建系统陷入困境吗？例如，有没有更快的符号链接替代方案？

补充：我看过有关递归 makefile 的论文。有谁直接知道将一个 Makefile 系统扁平化会产生什么影响，该系统目前有许多 makefile（大约 800 个）和超过 450 万个源代码行？人们目前喜欢通过在该目录中使用 make 来构建他们当前的子目录或进程（嵌入式 linux 目标）。

我刚刚了解到，直到最近，构建的时间是原来的两倍 (wince)，此时发布工程师部署了 ccache。

Answer 1

加快构建速度的注意事项：

构建往往受 I/O 限制，因此将 I/O 分布在多个驱动器/控制器或机器上。例如，将源放在一个物理驱动器上，将目标（构建输出）放在另一个物理驱动器上，并将这两个驱动器与包含构建工具（.NET、Java、Ant 等）的物理驱动器分开。 ) 以及包含您的操作系统的物理驱动器。

构建通常可以异步完成，因此建立并使用单独的构建机器（持续集成服务器）。将此特别用于计算指标、生成文档、生成候选版本以及其他任何需要太长时间或在开发人员的工作站上不需要的事情。

构建工具通常涉及大量进程启动/关闭开销，因此请选择能够最大限度减少该开销的工具、脚本和过程。对于像 make 和 Ant 这样倾向于将其他工具作为子流程调用的工具尤其如此。例如，我正在转向基于 Python 的构建系统，这样我就可以从单个进程完成大部分构建处理，但仍然能够在必要时轻松生成其他进程。

构建工具通常支持基于检测到它们将不执行任何操作而跳过构建步骤（不要编译，因为自上次编译以来源未更改）。但是，默认情况下，对跳过构建步骤的支持通常是不活动的——您可能需要专门调用它。例如，编译器通常会自动执行此操作，但代码生成不会。当然，这样做的一个必然结果是尽可能使用增量构建（在您的工作站上开发时，只要它“行为”）。

构建脚本可以快速轻松地变得非常复杂，因此请花时间让它们变得简单。首先，将构建分成单独的项目，每个项目只构建一个“工件”，例如 JAR、DLL 或 EXE。这允许您通过仅不调用您目前不需要的长构建来节省大量时间。其次，通过从不进入另一个项目来简化每个项目的构建——始终通过构建工件而不是源来建立项目依赖关系。这将使每个项目独立，您可以使用“超级”脚本随意构建项目的各种子集。

最后，将您的构建基础架构视为一个真正的项目——记录错误和针对它的功能请求、版本化、执行官方发布，并无限期地继续完善它。将其视为必不可少的产品，而不是事后的想法：您的构建是任何健康项目的命脉，如果您关心它，它可以节省您的面包。

Answer 2

我不确定为什么在您的情况下需要符号链接。如果您从同一个源构建多个目标，您可以尝试将中间文件和目标文件放在不同的目录中。

此外，您可以尝试使用jam 之类的东西，而不是嵌套的makefiles。如果你有多个 CPU，可以试试make -jn，其中 n 是 CPU 的数量 + 1。

Answer 3

如果您有不止一台计算机可供编译，您也可以使用distcc。这将构建过程分散到多台计算机上，结合 make -j 2 可以进一步加快速度。

根据项目的大小，瓶颈实际上可能出在编译器上（即您启用了 -O2 或 -O3），除了缩小源代码或删除未使用的#include 文件。

Answer 4

提到嵌套生成文件表明"Recursive Make Considered Harmful" 中建议的方法可能会有所帮助。摘自：

分析表明，问题源于人为地将构建划分为单独的子集。这反过来又会导致所描述的症状。为了避免症状，只需要避免分离；为整个项目使用单个 Makefile。

（单个逻辑makefile仍然可以由多个物理文件组成。）

Answer 5

我们使用冰淇淋。不是在构建时消磨时间，而是加快构建过程。它是一个分布式编译环境，使用办公室所有PC的空闲CPU时间。我们的设置非常复杂，因为我们有一个交叉编译环境，但如果您不进行交叉编译，它可能会简单得多。 http://en.opensuse.org/Icecream