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