C++持续集成的增量构建
我们在 VS2005 中构建了一个相当大的 C++ 项目，从头开始编译和构建可能需要长达 40 分钟的时间，安装程序还需要 10 分钟，因为该软件是在 32 位和 64 位配置中构建的。我希望将这个时间减少到至少 10 分钟左右，因为我觉得在使用持续集成时获得快速构建反馈很重要。
当通过删除最终链接文件而不是 .obj 文件来使用增量构建时，构建过程似乎要快得多，但似乎会到处弹出错误，例如无法加载 .dll。从干净的构建开始一切正常。我选择使用 TeamCity 作为 CI 系统。
也许增量构建行为在 Visual Studio 的更高版本中更好，并且可能是升级的良好动力？有人遇到过类似的问题吗？
We have a fairly large C++ project built in VS2005 that can take up to 40 minutes to compile and build from scratch, and a further 10 minutes for the installers as the software is being built in both 32-bit and 64-bit configurations. I would like to reduce this time to somewhere around 10 minutes at least as I feel it's important to get fast build feedback when using continuous integration.
When using incremental builds by deleting the final linked files but not the .obj files the build process seems to go much faster, however errors seem to pop up here and there, such as .dlls not being able to be loaded. From a clean build everything works fine. I am using TeamCity as the CI system of choice.
Maybe the incremental build behavior is better in later versions of Visual Studio and it might be a good motivation to upgrade ? Has anyone encountered similar issues?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我实际上无法回答您的问题，但由于您正在寻求加快构建速度，这篇关于使用 Visual Studio 2010 和 SSD 进行快速构建的博客文章可能会有所帮助。 http://qualapps.blogspot.com/2010/09 /lightning-fast-builds-with-visual.html
I can't actually answer your question, but since you're looking for speeding up your builds, this blog post about fast builds with Visual Studio 2010 and an SSD might be helpful. http://qualapps.blogspot.com/2010/09/lightning-fast-builds-with-visual.html
好问题。
当我为 Microsoft Visual Studio 2003/2005/2008 的大型 C++ 项目组装 CI 系统时，我也遇到了增量构建的问题。特别是在使用预编译头时，似乎并非在所有情况下都可以进行增量构建。我很想听听是否有人对此有详细的解释，即什么有效，什么无效。
就我而言，该项目从头开始构建需要一个多小时，因此为了在日内获得合理的反馈速度，我最终进行了一次干净的夜间构建，即发布构建，而日内我使用了基于每晚。除了增量构建无法正确获取更改并重新编译所有必要内容的情况外，这种方法效果相当好。我尝试这种方法是因为我认为快速获得反馈非常重要，如果增量构建每月或更少失败一次，我就准备好接受妥协。
一般来说，我喜欢比上面描述的更好的东西，因此在其他可以获得更多硬件并重新组织要并行构建的组件的项目中，我通常会进行完整的重新构建。如果您可以并行构建，则可以大大加快构建速度。
其他需要考虑的事情是：
有很多事情可以做来加快构建速度，在大多数情况下我会考虑将这些视为增量构建。
Good question.
When I was putting together a CI system for a large C++ project for Microsoft Visual Studio 2003/2005/2008 I enounteded problems as well with incremental builds. Especially when using pre-compiled headers it seems to not work under all circumstances to do an incremental build. I would be interested hear if someone has a detailed explanation of this, i.e. what works and what doesn't.
In my case, the project took more than one hour to build from scratch, so in order to have some reasonable speed of feedback intraday, I ended up doing a clean nightly build which was the release build and intraday I used incremental builds based on the nightly. This worked fairly well, except for cases when the incremental building wasn't able to pick up changes correctly and re-compile all necessary things. I tried this approach because I consider getting feedback fast very important and if the incremental build fails once a month or less, I was ready to live with the comprimise.
In general, I like to have things better than what I described above, so in other projects where it has been possible to get more hardware and re-organize the components to be built in parallel, I usually do complete re-builds. If you can do builds in parallel you can speed up building a lot.
Other things to consider are:
There are a lot of things which can be done to get building faster and I would in most cases consider these to incremental builds.
我的经验是，尤其是对于调试版本，瓶颈通常是磁盘 IO。它有助于压缩输出和中间文件目录。另外，我发现一些构建在不使用增量链接功能时速度更快（启用增量链接 - 否）。要考虑的另一个设置是关闭浏览信息生成（启用浏览信息 - 无）。另外，不要忘记使用 VS 2005 的并行编译功能。由于通常 IO 是瓶颈，因此使用比 CPU 多的构建线程会有所帮助。
My experience is that often, especially for debug builds, the bottleneck is disk IO. It helps to compress the output and intermediate files directories. Also, I have seen some builds being faster when not using incremental linking feature (Enable Incremental Linking - No). Another setting to consider is to turn off browse information generation (Enable Browse Information - None). Also, do not forget to use the parallel compilation feature of VS 2005. Since often it is the IO that is the bottleneck, it helps to use more build threads than there are CPUs.
我自己从未注意到这种行为，但我首先怀疑链接时间代码生成。对于持续集成，您可以跳过它。
我还应该提到 IncrediBuild。使用硬件来解决问题，尤其是您已经拥有的硬件，是一个快速的胜利。
Never noticed the behavior myself, but I would first suspect Link Time Code Generation. For continuous integration, you could skip that.
I should also mention IncrediBuild. Throwing hardware at the problem, especially hardware that you already have, is a quick win.