我有时会在 Visual C++(目前是 2003 年)上进行增量重建时遇到问题。有些依赖项似乎没有正确检查,有些文件没有在应该构建的时候构建。我想这些问题来自增量重建的时间戳方法。
在我的办公桌上构建调试版本时,我不认为这是一个大问题,但是对于可分发的构建,这是一个问题。
对构建服务器使用增量构建是否安全,还是需要完整构建?
我有时会在 Visual C++(目前是 2003 年)上进行增量重建时遇到问题。有些依赖项似乎没有正确检查,有些文件没有在应该构建的时候构建。我想这些问题来自增量重建的时间戳方法。
在我的办公桌上构建调试版本时,我不认为这是一个大问题,但是对于可分发的构建,这是一个问题。
对构建服务器使用增量构建是否安全,还是需要完整构建?
如果用户遇到需要调查的问题,您需要一个您分发的构建以便再次重新创建。
我不会依赖增量构建。此外,我总是会从构建机器中删除所有源代码,并在构建版本之前从源代码控制系统中从头开始获取它。这样,您就知道可以通过获取相同的源代码再次重复构建过程。
如果您使用增量构建,则每次构建都会有所不同,因为只需要构建系统的一个子集。我认为尽可能多地消除发布版本之间的差异是一件好事。因此,出于这个原因,增量构建已经结束。
用构建的版本号标记或以某种方式标记源代码控制系统中每个源文件的版本是一个好主意。这使您能够跟踪构建版本的确切来源。有了一个体面的源代码控制系统,标签可以用来追踪在一个版本和下一个版本之间对代码所做的所有更改。当您试图追踪您知道在两个版本之间引入的错误时,这可能是一个真正的帮助。
当您不分发构建时,增量构建在开发机器上仍然有用,只是为了在代码/调试/测试/重复开发周期中节省时间。
如果没有别的,我总是更愿意为任何版本做一个完整的清理和重建,以便让您高枕无忧。假设您谈论的是外部发布的构建,而不仅仅是使用 Release 配置的构建,这些构建相对不频繁的事实意味着从长远来看,任何时间节省都将是最小的。
我认为你应该避免“它是否安全”的问题。根本不值得研究。
增量构建的优点是节省成本。每个构建很小,它为开发人员通常制作的所有调试构建加起来,然后为您团队中的所有开发人员进一步加起来。
另一方面,发布版本很少见。发布构建的成本不在于等待它们的开发人员,而是在需要验证它的测试人员团队中发现更多。
出于这个原因,我发现增量构建无疑可以节省调试构建的成本,但我拒绝花任何时间计算我从增量构建发布构建中获得的小额节省。
使用增量构建功能构建的二进制文件将变得更大更慢,即使对于发布版本也是如此,因为它们必须包含脚手架以启用对于完全优化的构建而言并非必需的增量构建。出于这个原因,我建议您不要使用增量构建。