这个系统能否加快建设速度？

Question

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

你知道有什么快速的事情可以检查，可能会陷入这个构建系统吗？例如，是否有更快的替代符号链接？

补充:我看过关于递归makefile的论文。有谁知道直接使用Makefile系统会产生什么样的效果?Makefile系统目前有许多Makefile(大约800)和超过450万行源代码？目前，人们喜欢通过在目录中使用make构建当前子目录或进程(嵌入式linux目标)。

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

Answer 1

加快构建的注意事项：

构建往往是I/O绑定的，因此在多个驱动器/控制器或机器之间分发I/O。例如，将源代码放在一个物理驱动器上，并将目标(构建输出)放在不同的物理驱动器上，并将这两个驱动器与包含构建工具(.NET、Java、Ant等)的物理驱动器分开。以及包含你的操作系统的物理驱动器。

构建通常可以异步完成，因此建立和使用单独的构建机器(连续集成服务器)。特别是将其用于计算度量、生成文档、生成发布候选文件以及开发人员工作站上需要太长时间或不需要的其他任何东西。

构建工具通常涉及大量的进程启动/关闭开销，因此选择最小化这些开销的工具、脚本和过程。对于那些倾向于将其他工具作为子流程调用的make和Ant之类的工具来说，情况尤其如此。例如，我正在迁移到一个基于Python的构建系统，这样我就可以从单个进程完成大部分构建处理，但在必要时仍然能够轻松地生成其他进程。

构建工具通常支持跳过构建步骤，其基础是检测它们将什么也不做(不要编译，因为源代码自上次编译以来没有更改)。但是，对于跳过构建步骤的支持在默认情况下通常不是活动的--您可能需要具体地调用它。例如，编译器通常会自动这样做，但是代码生成不会。当然，这样做的必然结果是在可能的时候使用增量构建(同时在工作站上进行开发，只要它“运行”)。

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

最后，将您的构建基础设施视为自己的真正项目--记录bug和针对它的特性请求，对其进行版本化，执行正式发布，并继续无限期地完善它。把它当作一种基本的产品，而不是事后想:你的构建是你任何健康项目的命脉，如果你关心它，它可以拯救你的面包。

Answer 2

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

另外，您可以尝试使用类似于制革剂的东西，而不是嵌套的果酱。如果您有多个CPU，可以尝试make -j n，其中n是CPU+ 1的数量。

Answer 3

如果有多台计算机可供编译，也可以使用远距离。这会将构建过程扩展到多台计算机上，这将与make -j 2一起进一步加快速度。

根据项目的大小，瓶颈可能实际上与编译器有关(即您正在启用-O2或-O3)，除了缩小源代码或删除未使用的#include文件之外，可能没有什么可做的。