我们都听到了 - "尝试一个干净的构建，看看它是否有效"。经过重建后，怪异的运行时间错误通常会消失。这使我想到 - 正确跟踪依赖关系是构建系统的工作。
是这样的运行时错误根据构建系统中的定义错误 - 无论是制造，还是MSBUILD，还是任何一个。或换句话说，如果干净的构建和正常构建产生不同的结果，则根据定义，构建系统中的错误？
编辑：我假设构建环境是理智的 - 意味着，当文件更新时，其"最后修改"时间戳将变得更新（而不是较旧的时间戳或相同的时间戳）。实际上，我知道遵循该规则的所有版本控制系统，因为否则它们会破坏构建系统，例如，依靠时间戳来跟踪需要更新的文件。
可以优化构建系统以表现或完整性。
重建所有都是完整的。
部分重建失败的原因是
- 不正确的知识。构建了库，但是零散的构建系统不了解整体的依赖性。
- 缺少依赖性。尽管已理解了标头对C代码的直接依赖关系，但却错过了间接依赖。
- 编辑并继续错误编译。部分构建中间理解代码更改的后果，并且不够重新编译。
所有这些错误都被优势所抵消
- 更简单地维护制作文件
- 更快的编译
- 更快的错误转身
您需要对价值所在的位置做出自己的判断