部分构建与Visual C ++中的完整构建

Question

对于我使用Visual C ++进行的大多数开发工作，我使用的是部分构建，例如：按F7并仅更改C ++文件并重建其依赖项，然后是增量链接。在将版本传递给测试之前，我会采取预防措施进行完全重建，这对我当前的项目大约需要45分钟。我看过很多帖子和文章提倡这个动作，但是这是必要的，如果有的话，为什么呢？它是否会影响交付的EXE或相关的PDB（我们也在测试中使用）？软件的功能与测试角度有何不同？

对于发布版本，我正在使用VS2005，增量编译和链接，预编译头文件。

Answer 1

部分构建系统的工作原理是根据构建结果检查源文件的文件日期。所以它可能会破坏你，例如从源代码管理中恢复早期文件。早期文件的修改日期早于构建产品，因此不会重建产品。为了防止出现这些错误，如果是最终版本，则应该进行完整构建。在开发过程中，增量构建当然要高效得多。

编辑：当然，进行完全重建还可以防止增量构建系统中出现可能的错误。

Answer 2

基本问题是编译依赖于环境（命令行标志，可用库，可能还有一些Black Magic），因此如果在相同条件下执行，则两个编译只会产生相同的结果。对于测试和部署，您希望确保环境尽可能受到控制，并且由于奇怪的代码而您没有获得古怪的行为。一个很好的例子是如果你更新一个系统库，然后重新编译一半的文件 - 一半仍在尝试使用旧代码，一半不是。在一个完美的世界中，这可能会立即出错或者不会引起任何问题，但遗憾的是，有时这些都不会发生。因此，执行完整的重新编译可避免与交错构建过程相关的许多问题。

Answer 3

是不是每个人都遇到过这种使用模式？我得到了奇怪的构建错误，在调查之前我进行了完全重建，问题就消失了。

在我看来这本身就足以让你在发布之前进行完全重建。

我认为，无论你是否愿意将没有问题而完成的增量构建转换为测试，都是一种品味问题。

Answer 4

我肯定会推荐它。我已经在很多场合看到过使用大型Visual C ++解决方案，依赖检查程序无法获得对已更改代码的某些依赖。当这个改变是一个影响对象大小的头文件时，很奇怪的事情就会开始发生。 我确信依赖检查程序在VS 2008中有所改进，但我仍然不相信它的发布版本。

Answer 5

不发布增量链接二进制文件的最大原因是某些优化被禁用。链接器将在函数之间留下填充（以便在下一个增量链接上更容易替换它们）。这给二进制文件增加了一些膨胀。可能还有额外的跳转，这会改变内存访问模式，并可能导致额外的分页和/或缓存未命中。旧版本的函数可能会继续驻留在可执行文件中，即使它们从未被调用过。这也会导致二进制膨胀和性能下降。而且你当然不能使用增量链接生成链接时代码，所以你错过了更多的优化。

如果你给测试人员一个调试版本，那么它可能不是什么大问题。但是您的发布候选版本应该在发布模式下从头开始构建，最好是在具有受控环境的专用构建机器上构建。

Answer 6

Visual Studio在部分（增量）构建方面存在一些问题，（我经常遇到链接错误）不时，完全重建是非常有用的。

如果编译时间较长，则有两种解决方案：

1. 使用并行编译工具并利用您的（假定的）多核硬件。
2. 使用构建机器。我最常用的是一个单独的构建机器，设置了CruiseControl，可以不时执行完全重建。我向测试团队提供的“官方”版本，以及最终提供给客户的版本，总是来自构建机器，而不是来自开发人员的环境。