MSBuild / Visual Studio 分布式构建答案

【问题标题】：MSBuild / Visual Studio distributed buildsMSBuild / Visual Studio 分布式构建
【发布时间】：2009-11-05 16:16:00
【问题描述】：

我开发/维护了一个需要很长时间才能构建的应用程序（例如，完整的构建需要六个多小时！）。在花了一天的大部分时间构建我们的应用程序之后，我开始寻找改进构建时间的方法。 on this Stack Overflow question 的建议是：

修复编译警告
Unity 构建（面向开发人员）
分布式构建

我想详细了解如何为 MSBuild / Visual Studio 构建系统执行第三个选项（分布式构建）。

【问题讨论】：

标签： c++ msbuild

【解决方案1】：

去看看http://www.xoreax.com/ 了解 Incredibuild。它不是免费的，但我们使用它，它令人印象深刻。它很好地集成到 Visual Studio 中，使用起来非常简单。您可能会时不时地遇到问题，但绝对值得一看。

安装后，在 Visual Studio 中，原则是使用“使用 Incredibuild 构建解决方案”菜单条目而不是“构建解决方案”菜单条目。所有需要的文件都被透明地传输到远程计算机，并且输出文件被下载回来。

【讨论】：

我必须同意 Xoreax 的 Incredibuild。是的，它需要花钱，但可以在几周内让开发人员工作而不是看着他们的计算机编译来偿还。
我认为它不支持 MSBuild - 您需要编写自己的 MSbuild 任务来包装它。应该不会太难，但这是额外的工作。
我还看到 IncrediBuild 在加速构建方面做得非常可靠。我们遇到的唯一问题是自定义构建步骤，它并不总是很好。这是否会影响您的项目是一个单独的问题。

【解决方案2】：

在过去十年中，我花了太多时间让 C++ 构建速度更快，并行构建可以创造奇迹，但简单的事情有时会产生惊人的差异。

你没有说很多细节，所以我会问......

项目规模如何？有多少源文件等。我过去使用的一个指标是每个源模块 (.cpp) 的平均目标是一秒。从 200 到超过 32,000 行（不是拼写错误！）的来源，这在我过去作为一个指标非常有效。

您的构建机器的规格是什么，它是仅一台构建机器还是同时用于其他工作？傻傻的硬盘慢，RAM太少，其他进程使用；所有这些都可能对构建时间造成灾难性影响。

您是否在构建单体静态库和应用程序？如果是这样，有时转换为 DLL 文件会降低整体构建时间，因为它会降低单个链接单元的数量。对于具有链接时代码生成的优化构建尤其如此。

您的项目是否有效地使用了预编译头文件？如果您的项目设置为自动生成预编译头文件，那么我断言您应该通过关闭所有预编译头文件的使用来测试构建。在Visual Studio 2003 和Visual Studio 2005 中，我发现这实际上比自动生成更快、更可靠。正确的预编译头文件（由一个仅执行并由所有其他文件使用的文件生成）似乎是最佳构建速度的过程。可悲的是，为给定项目获得最佳 PCH 内容是一种真正的黑艺术，并且在某种程度上需要反复试验——而且这些内容在项目的生命周期内不一定是稳定的。

除了您的并行任务之外，上述内容只会有所帮助。

【讨论】：

【解决方案3】：

调查将您的项目拆分为多个可以独立构建的项目的可行性。您可以有一个用于 UI 的项目、用于数据访问层、业务逻辑等的 DLL 项目。这应该会使调试变得相当容易，并以适合分布式构建的方式构建您的项目。

【讨论】：

【解决方案4】：

理论上，使用 Visual Studio 2010，您可以编写自己的 msbuild 任务，这些任务可以安排任务并将代码流式传输到其他机器进行编译。

使用以前版本的 Visual Studio，您可以覆盖 cl.exe、lib.exe 和 link.exe 并创建自己的包装器。该技术已成功用于添加不受支持的平台类型的编译和链接。

【讨论】：

【解决方案5】：

TeamBuild 将为您提供与 Visual Studio 完美集成的分布式构建系统。

【讨论】：

【解决方案6】：

Scott Hanselman 有一篇关于并行构建的帖子here。它不是完全分发的，但它可能会对一些人有所帮助。

另外请注意，MSBuild 本身并不构建 C++ 项目。它实际上调用 vcbuild 来为它做脏活。

【讨论】：