Visual C 中的部分构建与完整构建
对于我使用 Visual C++ 进行的大部分开发工作，我使用部分构建，例如按 F7，仅更改 C++ 文件及其依赖项，然后重新构建增量链接。 在将版本进行测试之前，我会采取预防措施进行完整重建，这在我当前的项目中大约需要 45 分钟。 我看过很多提倡这一行动的帖子和文章，但想知道这是否有必要，如果有的话，为什么？ 它是否会影响交付的 EXE 或关联的 PDB（我们也在测试中使用）？ 从测试的角度来看，该软件的功能会有什么不同吗？
对于发布版本，我使用 VS2005、增量编译和链接、预编译头。
For most of my development work with Visual C++, I am using partial builds, e.g. press F7 and only changed C++ files and their dependencies get rebuilt, followed by an incremental link. Before passing a version onto testing, I take the precaution of doing a full rebuild, which takes about 45 minutes on my current project. I have seen many posts and articles advocating this action, but wonder is this necessary, and if so, why? Does it affect the delivered EXE or the associated PDB (which we also use in testing)? Would the software function any different from a testing perspective?
For release builds, I'm using VS2005, incremental compilation and linking, precompiled headers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
部分构建系统通过根据构建结果检查源文件的文件日期来工作。 因此，如果您从源代码管理恢复较早的文件，它可能会损坏。 较早的文件的修改日期早于构建产品，因此不会重建产品。 为了防止这些错误，如果是最终构建，您应该执行完整的构建。 不过，当您进行开发时，增量构建当然会更加高效。
编辑：当然，进行完全重建还可以保护您免受增量构建系统中可能出现的错误的影响。
The partial build system works by checking file dates of source files against the build results. So it can break if you e.g. restore an earlier file from source control. The earlier file would have a modified date earlier than the build product, so the product wouldn't be rebuilt. To protect against these errors, you should do a complete build if it is a final build. While you are developing though, incremental builds are of course much more efficient.
Edit: And of course, doing a full rebuild also shields you from possible bugs in the incremental build system.
基本问题是编译依赖于环境（命令行标志、可用的库，可能还有一些黑魔法），因此两个编译只有在相同的条件下执行才会有相同的结果。 对于测试和部署，您希望确保环境尽可能受到控制，并且不会由于奇怪的代码而出现古怪的行为。 一个很好的例子是，如果您更新系统库，然后重新编译一半文件 - 一半仍在尝试使用旧代码，一半则不会。 在完美的世界中，这要么立即出错，要么不会造成任何问题，但遗憾的是，有时这两种情况都不会发生。 因此，进行完整的重新编译可以避免与交错构建过程相关的许多问题。
The basic problem is that compilation is dependent on the environment (command-line flags, libraries available, and probably some Black Magic), and so two compilations will only have the same result if they are performed in the same conditions. For testing and deployment, you want to make sure that the environments are as controlled as possible and you aren't getting wacky behaviours due to odd code. A good example is if you update a system library, then recompile half the files - half are still trying to use the old code, half are not. In a perfect world, this would either error out right away or not cause any problems, but sadly, sometimes neither of those happen. As a result, doing a complete recompilation avoids a lot of problems associated with a staggered build process.
大家都没有遇到过这种使用模式吗？ 我遇到了奇怪的构建错误，在调查之前我进行了完全重建，问题就消失了。
在我看来，这本身就是在发布之前进行完全重建的充分理由。
我认为，您是否愿意将没有问题完成的增量构建转而进行测试，这是一个品味问题。
Hasn't everyone come across this usage pattern? I get weird build errors, and before even investigating I do a full rebuild, and the problem goes away.
This by itself seems to me to be good enough reason to do a full rebuild before a release.
Whether you would be willing to turn an incremental build that completes without problems over to testing, is a matter of taste, I think.
我肯定会推荐它。 我曾多次在大型 Visual C++ 解决方案中看到依赖项检查器无法检测到对已更改代码的某些依赖项。 当头文件的这种变化影响对象的大小时，就会开始发生非常奇怪的事情。
我确信 VS 2008 中的依赖性检查器已经变得更好，但我仍然不相信它用于发布版本。
I would definitely recommend it. I have seen on a number of occasions with a large Visual C++ solution the dependency checker fail to pick up some dependency on changed code. When this change is to a header file that effects the size of an object very strange things can start to happen.
I am sure the dependency checker has got better in VS 2008, but I still wouldn't trust it for a release build.
不发布增量链接二进制文件的最大原因是某些优化被禁用。 链接器将在函数之间留下填充（以便更容易在下一个增量链接中替换它们）。 这会给二进制文件增加一些膨胀。 还可能存在额外的跳转，这会改变内存访问模式并可能导致额外的分页和/或缓存未命中。 旧版本的函数可能会继续驻留在可执行文件中，即使它们从未被调用。 这也会导致二进制膨胀和性能下降。 而且您当然不能将链接时代码生成与增量链接一起使用，因此您会错过更多优化。
如果您向测试人员提供调试版本，那么这可能不是什么大问题。 但是您的候选版本应该在发布模式下从头开始构建，最好是在具有受控环境的专用构建机器上。
The biggest reason not to ship an incrementally linked binary is that some optimizations are disabled. The linker will leave padding between functions (to make it easier to replace them on the next incremental link). This adds some bloat to the binary. There may be extra jumps as well, which changes the memory access pattern and can cause extra paging and/or cache misses. Older versions of functions may continue to reside in the executable even though they are never called. This also leads to binary bloat and slower performance. And you certainly can't use link-time code generation with incremental linking, so you miss out on more optimizations.
If you're giving a debug build to a tester, then it probably isn't a big deal. But your release candidates should be built from scratch in release mode, preferably on a dedicated build machine with a controlled environment.
Visual Studio 在部分（增量）构建方面存在一些问题，（我主要遇到链接错误）有时，进行完全重建非常有用。
如果编译时间较长，有两种解决方案：
Visual Studio has some problems with partial (incremental) builds, (I mostly encountered linking errors) From time to time, it is very useful to have a full rebuild.
In case of long compilation times, there are two solutions: