使用增量重建在 Visual C++ 中生成发布版本是否安全？
我有时会遇到 Visual C++ 增量重建问题（目前为 2003 年）。 有些依赖项似乎没有正确检查，有些文件在应该构建时没有构建。 我认为这些问题来自增量重建的时间戳方法。
在我的桌面上构建调试版本时，我不认为这是一个大问题，但是对于可分发版本来说，这是一个问题。
对构建服务器使用增量构建是否安全，或者是否需要完整构建？
I sometimes have issues with the incremental rebuild on visual C++ (2003 currently ). Some dependencies does not seem correctly checked and some files aren't build when they should. I suppose thoses issues come from the timestamp approach to incremental rebuild.
I don't consider it a huge issue when building debug build on my desk, however for distribuable build this is a issue.
Is it safe to use incremental build for a build server or is a full build a requirement ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果用户遇到需要调查的问题，您需要分发一个可以再次重新创建的构建。
我不会依赖增量构建。 另外，我总是会从构建机器中删除所有源代码，并在构建版本之前从源代码控制系统中从头开始获取它。 这样，您就知道可以通过获取相同的源代码来再次重复构建过程。
如果您使用增量构建，则每次构建都会有所不同，因为只需要构建系统的一个子集。 我认为尽可能消除发布版本之间可能存在的差异是件好事。 因此，出于这个原因，增量构建已经过时了。
最好使用构建的版本号来标记或以某种方式标记源控制系统中每个源文件的版本。 这使您能够跟踪构建版本的确切来源。 有了一个像样的源代码控制系统，标签可以用来追踪一个版本和下一个版本之间对代码所做的所有更改。 当您尝试追踪两个版本之间引入的错误时，这可能会很有帮助。
当您不分发构建时，增量构建在开发机器上仍然有用，只是为了在代码/调试/测试/重复开发周期中节省时间。
You need a build you distrubute to be recreatable again should users experience problems that need investigating.
I would not rely on an incremental build. Also, I would always delete all source from the build machine, and fetch it from scratch from the source control system before building a release. This way, you know you can repeat the build process again by fetching the same source code.
If you use an incremental build, the build will build differently each time because only a subset of the system will need to be built. I think its just good to eliminate as many possible differences between release builds as possible. So, for this reason incremental builds are out.
It's a good idea to label or somehow mark the versions of each source file in the source control system with the version number of the build. This enables you to keep track of the exact source that went into building the release. With a decent source code control system the labels can be used to track down all the changes that were made to the code between one release and the next. This can be a real help when trying to track down a bug that you know was introduced between the two releases.
Incremental builds can still be useful on a development machine when you're not distributing the build, just for saving time during the code/debug/test/repeat development cycle.
我认为你应该避免“安全吗”的问题。 这根本不值得研究。
增量构建的优点是节省成本。 每个构建都很小，它累加了开发人员通常所做的所有调试构建，然后进一步累加了团队中的所有开发人员。
另一方面，发布版本很少见。 发布版本的成本不在于开发人员等待它们，而更多地在于需要验证它的测试人员团队。
出于这个原因，我发现增量构建无疑可以节省调试构建的成本，但我拒绝花任何时间来计算增量构建发布构建所带来的小额节省。
I'd argue that you should avoid the "is it safe" question. It's simply not worth looking into.
The advantage of incremental builds is the cost saving. Small per build, it adds up for all the debug builds a developer typically makes, and then adds up further for all developers on your team.
On the other hand, release builds are rare. The costs of a release build are not in developers waiting on them, they're found much more in the team of testers that need to validate it.
For that reason, I find that incremental builds are without a doubt cost-saving for debug builds, but I refuse to spend any time calculating the small saving I'd get out of incrementally building a release build.
如果没有别的事情的话，我总是更愿意对任何版本进行彻底的清理和重建，以求安心。 假设您讨论的是外部发布的构建，而不仅仅是使用发布配置的构建，那么这些构建相对不频繁的事实意味着从长远来看，节省的时间将是最少的。
I would always prefer to do a full clean and rebuild for any release for peace of mind if nothing else. Assuming that you're talking about externally released builds and not just builds using the Release configuration, the fact that these builds are relatively infrequent means that any time saving will be minimal in the long run.
使用增量构建功能构建的二进制文件将会更大、更慢，即使对于发布构建也是如此，因为它们必须包含脚手架来启用增量构建，而这对于完全优化的构建来说是不必要的。 由于这个原因，我建议您不要使用增量构建。
Binaries built using with the incremental build feature are going to be bigger and slower, even for release builds, because they necessarily contain scaffolding to enable the incremental builds that isn't necessary for fully optimized builds. I'd recommend you not to use incremental builds for this reason.