建立安全的团结 我使用一个大型的C++项目，它使用Unity构建。对于不熟悉实际的人，Unity将包含多个相关C++实现文件包含到一个大型编译单元中，然后编译为一个大型编译单元。这节省了重新编译的头文件，减少了链接时间，通过在内部链接中引入更多的函数来提高可执行文件的大小/性能，等等。这些通常都是好东西

然而，我刚刚在我们的一个构建中发现了一个潜在的bug。在库中使用的一个实现文件，不包括相关的头文件，但它已编译并运行。在摸了摸脑袋之后，我意识到它被包含在unity构建之前的一个实现文件中。在这里没有什么害处，但如果有人后来试图独立地重用该文件，这可能会是一个令人困惑的惊喜

---

除了定期构建非Unity版本外，还有什么方法可以捕获这些静默依赖项并保留Unity构建的好处吗？

我以前在源代码存储库中使用过UB方法来冻结我们从未计划再次维护的项目。不幸的是，我很确定你的问题的答案是否定的。如果你想测试这些类型的错误，你必须定期分别构建所有的cpp文件

---

可能最接近automagic解决方案的是buildbot，它自动收集项目中的所有cpp文件（UB文件除外），并定期从源存储库构建，同时指出任何构建错误。这样，您的本地开发速度仍然很快（使用UBs），但您仍然可以从这些定期buildbot构建中捕获任何错误，这些构建分别构建所有CPP。

我建议不要在您的本地开发环境中使用unity build。不管怎样，在编辑和编译时，Unity Build都不会帮助您提高编译时间。仅将Unity Build用于非增量连续构建系统，您不希望使用该系统的生产

只要每个人都在本地编译后提交更改，就不会出现您描述的情况

而Unity Build可能会在本地定义的函数之间形成意外的重载调用，这些函数恰好使用了重复的名称。这是危险的，而且您没有意识到这一点，即在这种情况下可能不会生成编译错误或警告。除非你有办法阻止，否则请不要回复Unity Build生成的产品