C++增量构建用于持续集成

Question

我们有一个相当大的C++项目，使用VS2005构建，从头开始编译和构建可能需要长达40分钟的时间，并且由于软件在32位和64位配置中构建，安装程序还需要额外的10分钟。我希望将这个时间缩短到至少10分钟，因为在使用持续集成时，快速的构建反馈非常重要。

当通过删除最终链接文件而不是.obj文件来使用增量构建时，构建过程似乎会快得多，但是会出现一些错误，例如无法加载.dll文件。从干净的构建开始，一切都正常。我使用TeamCity作为首选的CI系统。

也许增量构建行为在Visual Studio的后续版本中更好，这可能是升级的一个好动机？有人遇到类似的问题吗？

- Can Gencer

---

你能详细说明一下你提到的错误吗？我很难理解为什么部分构建会引发DLL加载问题。这是否意味着您必须始终对项目进行全新的构建才能使其正常工作？ - rotoglup

我们有一个小脚本，调用LoadLibrary()加载所有的.dll文件，以确保满足所有依赖要求。似乎对于某些.dll文件会失败。如果我们通过Visual Studio构建或使用命令行中的msbuild并调用两次，则问题似乎不会发生。但我认为增量构建取决于源代码日期，当TeamCity从存储库更新代码时，文件上的修改日期也可能会被还原（我们正在使用Mercurial）。我将进一步调查这个问题。 - Can Gencer

Answer 1

我实际上无法回答你的问题，但是如果你正在寻找加速构建的方法，这篇关于使用Visual Studio 2010和SSD进行快速构建的博客文章可能会有所帮助。http://qualapps.blogspot.com/2010/09/lightning-fast-builds-with-visual.html

- Marius Bancila

---

谢谢提供的链接。我一直在考虑固态硬盘（SSD）以及升级CPU。显然，你总是可以通过增加硬件来解决问题，但我希望找到一种可靠的方法使增量构建正常工作，如果成功的话，配合新硬件将会更快速。 - Can Gencer

现在，我不想让你感到困惑：）但是也有关于SSD的相反意见，比如Jeff Palermo的这篇文章。http://jeffreypalermo.com/blog/speeding-up-the-build-ndash-ditch-the-ssd-and-go-for-the-ram-drive/ - Marius Bancila

Answer 2

我的经验是，特别是对于调试构建而言，瓶颈往往是磁盘IO。 压缩输出和中间文件目录有助于解决问题。 另外，我发现在不使用增量链接功能时（启用增量链接 - 否），某些构建速度更快。 考虑的另一个设置是关闭浏览信息生成（启用浏览信息 - 无）。 此外，不要忘记使用VS 2005的并行编译功能。由于通常是IO成为瓶颈，因此使用比CPU数量更多的构建线程会有所帮助。

- wilx

---

是的，我们正在使用“未记录”的并行构建标志，并且它有所帮助。我将尝试设置一个ramdisk或类似的东西，看看是否可以帮助这个过程。 - Can Gencer

@Can Gencer：什么是未记录的并行构建标志？我指的是“工具-选项-项目和解决方案-生成和运行-最大并行项目生成”设置。如果您正在使用MSBuild或VCBuild，则两者都具有同样效果的一些选项。 - wilx

你的意思是并行构建项目。我没有尝试过，因为我记得很久以前读到过这不是很可靠。我会尝试一下。我指的是多核编译的 /MP 标志。它在 VS2008 中可用，在 VS2005 中作为未记录的标志。http://msdn.microsoft.com/en-us/library/bb385193.aspx - Can Gencer

Answer 3

我自己从未注意到这种行为，但我首先会怀疑链接时间代码生成。对于持续集成，您可以跳过它。

我还应该提到IncrediBuild。解决问题的方法之一是投入硬件资源，特别是您已经拥有的硬件资源。

- MSalters

---

所有项目都将其设置为“默认值”，我认为这意味着未启用。Incredibuild听起来很有趣，我会调查一下。 - Can Gencer

Answer 4

好问题。

当我为 Microsoft Visual Studio 2003/2005/2008 的一个大型 C++ 项目组装 CI 系统时，我遇到了增量构建的问题。特别是在使用预编译头文件时，在所有情况下似乎都不能进行增量构建。如果有人能详细解释这一点，即什么有效而什么无效，我会很感兴趣听到。

在我的情况下，该项目从头开始构建需要超过一小时，因此为了获得合理的日内反馈速度，我最终进行了每晚清洁构建，这是发布构建，白天我则基于每晚的增量构建。这个方法效果还不错，只是增量构建没有正确捕捉到更改并重新编译所有必要的东西时会有问题。我尝试这种方法是因为我认为快速获取反馈非常重要，如果增量构建一个月或更少次数失败，我愿意接受这种妥协。

总的来说，我希望事情比我上面描述的更好，在其他项目中，如果有可能获得更多硬件并重新组织组件以并行构建，我通常会进行完全重新构建。如果你能并行构建，你可以极大地加速构建。

其他需要考虑的事项：

• 包含 vs. 前向声明
• 模板使用
• 事物之间的一般依赖关系
• 将项目的部分作为独立库提取出来，甚至可以预先构建。

有很多方法可以加快构建速度，在大多数情况下，我会考虑这些是增量构建。

- murrekatt