C++；增量构建用于持续集成 我们在VS2005中建立了一个相当大的C++项目，可以从头开始编译和编译，并且在32位和64位配置中构建软件的安装程序还要10分钟。我想把这个时间减少到至少10分钟左右，因为我觉得在使用持续集成时获得快速构建反馈很重要

当通过删除最终链接文件而不是.obj文件来使用增量生成时，生成过程似乎要快得多，但是错误似乎到处都会出现，例如.dll无法加载。从一个干净的建筑，一切都很好。我选择TeamCity作为CI系统

---

在Visual Studio的较新版本中，增量构建行为可能更好，这可能是升级的良好动机？有人遇到过类似的问题吗？

我无法回答您的问题，但由于您正在寻求加快构建速度，这篇关于Visual Studio 2010和SSD快速构建的博客文章可能会有所帮助

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

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

我还应该提到难以置信的构建。用硬件解决问题，特别是你已经拥有的硬件，是一个快速的胜利。

好问题

当我为微软Visual Studio 2003/2005／2008为大型C++项目组装CI系统时，我也提出了问题以及增量构建。尤其是在使用预编译的头文件时，似乎并不是在所有情况下都可以进行增量构建。我很想听听是否有人对此有详细的解释，即什么有效，什么无效

在我的例子中，项目从零开始构建需要一个多小时，因此为了在日内获得合理的反馈速度，我最终完成了一个干净的夜间构建，即发布构建，并且在日内使用了基于夜间的增量构建。除了增量构建无法正确地获取更改并重新编译所有必要内容的情况外，这种方法工作得相当好。我尝试过这种方法，因为我认为快速获得反馈非常重要，如果增量构建失败一个月或更少一次，我就准备好了。 一般来说，我喜欢拥有比我上面描述的更好的东西，因此在其他项目中，如果可以获得更多硬件并重新组织并行构建的组件，我通常会完成重新构建。如果你可以并行构建，你可以大大加快构建速度

其他需要考虑的事情是：

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

---

有很多事情可以做得更快，我会在大多数情况下考虑这些增量构建。

谢谢链接。我一直在考虑SSD，以及升级CPU。很明显，你总是可以在这个问题上投入更多的硬件，我希望找到一种方法，使增量构建以可靠的方式工作，如果这种方法可行的话，使用新硬件会更快。现在，我不想让你感到困惑：），但对于SSD也有相反的观点，正如Jeff Palermo的观点。你能详细说明一下你提到的错误吗？我很难理解为什么部分构建会引发DLL加载问题。这是否意味着您总是为项目创建一个干净的构建以使其正常工作？我们有一个小脚本，用于在所有.dll上调用LoadLibrary（），以确保满足所有依赖项要求。对于某些.dll，它似乎失败了。如果我们通过VisualStudio构建，或者从命令行使用msbuild并调用它两次，那么问题似乎不会发生。但我认为增量构建取决于源代码日期，可能是当TeamCity从存储库更新代码时，文件上修改的日期也会恢复（我们使用的是mercurial）。是的，我们正在使用“undocumented”并行构建标志，这有点帮助。我将尝试设置一个ramdisk或类似的东西，看看这是否有助于这个过程。@Can Gencer:什么是Undocumented parallel build flag？我指的是“工具-选项-项目和解决方案-构建和运行-并行项目构建的最大数量”设置。如果您使用的是MSBuild或VCBuild，则两者都有一些具有相同效果的选项。您的意思是并行构建项目。我还没有试过，因为我记得很久以前读过，它不太可靠。我要试一试。我指的是多核编译的/MP标志。它在VS2008和VS2005中作为未记录的标志提供。所有项目都将其设置为“默认”，我认为这意味着未启用。难以置信的建筑听起来很有趣，我们将对此进行调查。