我们的构建是狗慢。它在linux上使用嵌套的gnu makefile。它为同一源树中的三个不同目标创建三个构建。它使用符号链接依次指向三个并行目录树中的每一个。我们可以使用make inside子目录进行部分构建，这样可以节省时间，但是如果我们的工作跨越多个目录，我们必须为三个目标中的至少一个构建，并且至少需要45分钟。只有子目录构建可能只需“5-10分钟”。
您是否知道要检查的任何快速事项可能会阻碍此构建系统？例如，是否有更快的符号链接替代方案？
补充：我看过有关递归makefile的文章。有没有人知道平面化Makefile系统会产生多种makefile（大约800个）和超过450万个源代码行的影响？人们目前喜欢通过在该目录中使用make来构建他们当前的子目录或进程（嵌入式linux目标）。
我刚刚了解到，直到最近，构建时间已经两倍（ wince ），此时发布工程师部署了ccache。
答案 0 :(得分：4)
我不确定为什么在你的情况下需要符号链接。如果要从同一源构建多个目标，可以尝试将中间文件和目标文件放在不同的目录中。
此外，您可以尝试使用类似makefiles的内容，而不是嵌套jam。如果您有多个CPU，则可以尝试make -j n ，其中 n 是CPU的数量+ 1。
答案 1 :(得分：4)
加速构建的注意事项：
构建往往受I / O限制，因此将I / O分布在多个驱动器/控制器或计算机上。例如，将源放在一个物理驱动器上并将目标（构建输出）放在不同的物理驱动器上，并将这两个驱动器与包含构建工具（.NET，Java，Ant等）的物理驱动器分开。 ）以及包含操作系统的物理驱动器。
构建通常可以异步完成，因此建立并使用单独的构建机器（持续集成服务器）。特别是用于计算指标，生成文档，生成候选版本以及开发人员工作站上需要太长时间或不需要的任何其他内容。
构建工具通常涉及大量进程启动/关闭开销，因此请选择最小化开销的工具，脚本和过程。对于像make和Ant这样的工具来说尤其如此，这些工具倾向于将其他工具作为子进程调用。例如，我正在转向基于Python的构建系统，以便我可以从单个进程完成大部分构建处理，但仍然能够在必要时轻松生成其他进程。
构建工具通常支持基于检测到它们什么都不做而跳过构建步骤（不进行编译，因为自上次编译以来源尚未更改）。但是，默认情况下，对跳过构建步骤的支持通常不活动 - 您可能需要专门调用它。例如，编译器通常会自动执行此操作，但代码生成则不会。当然，这样做的必然结果是尽可能使用增量构建（在工作站上进行开发时，只要它“行为”）。
构建脚本可以快速轻松地变得非常复杂，因此请花些时间让它们变得简单。首先，将构建分离为单独的项目，每个项目仅构建一个“工件”，例如JAR，DLL或EXE。这样，您只需不调用目前不需要的长版本，就可以节省大量时间。其次，通过不进入另一个项目来简化每个项目的构建 - 始终通过构建工件而不是源构建项目依赖项。这将使每个项目都独立，您可以使用“超级”脚本随意构建项目的各个子集。
最后，将您的构建基础架构视为自己的真实项目 - 记录对它的错误和功能请求，对其进行版本控制，执行官方发布，并继续无限期地对其进行优化。把它当成一种必不可少的产品而不是事后的想法：你的构建是任何健康项目的命脉，如果你关心它，它可以保存你的面包。
答案 2 :(得分：1)
如果您有多台计算机可供编译，您也可以使用distcc。这会将构建过程分散到多台计算机上，与make -j 2结合使用可以进一步加快速度。
根据项目的大小，瓶颈实际上可能与编译器有关（即你正在启用-O2或-O3），除了缩小源代码或删除之外，可能没有太多可以做的事情。未使用的#include文件。
答案 3 :(得分：1)
提到嵌套的makefile表明"Recursive Make Considered Harmful"中建议的方法可能有所帮助。从摘要：
分析表明问题源于将构建人工划分为单独的子集。反过来，这会导致所描述的症状。为了避免这种症状，只需要避免分离;为整个项目使用单个Makefile。
（单个逻辑makefile仍然可以由多个物理文件组成。）
答案 4 :(得分：0)
我们使用冰淇淋。不是为了在构建时消磨时间，而是为了加快构建过程。它是一个分布式编译环境，它使用办公室中所有PC的备用CPU时间。我们的设置非常复杂，因为我们有一个交叉编译环境，但如果你不进行交叉编译，它可能会简单得多。 http://en.opensuse.org/Icecream