为什么“out of source”构建不是默认值？

Question

我最近发现，你可以配置Visual Studio（但这个问题对于任何编译器都是一样的）将中间.o文件转储到源树之外的单独文件夹中，而不是与每个单独的项目一起。这样可以很容易地清理项目以存档到zip或其他类似的东西。

为什么这种配置不常见？有没有明显的缺点？

Answer 1

这可能是历史答案的问题。第一批C编译器（以及第一批C ++编译器）是针对Unix编写的。

在Unix中没有任何“标准”的地方，只有少数例外。因此，通常的做法是将所有内容放在当前工作目录中，除非另有说明。

Answer 2

这是Visual Studio中的默认，已经有一段时间了（至少可以追溯到VC ++ 6）。中间目录默认与输出目录相同，而不是源目录。这意味着所有目标文件都放在最终输出旁边。

事实上，如果您正在处理希望将编译器输出与源文件放在一起的项目，那么它需要一些jiggery-pokery。由于VC ++默认为对象文件提供与其对应源文件相同的名称（但具有不同的扩展名），如果您有多个具有相同名称（但路径不同）的源文件，则每个源文件的编译将覆盖相应的对象文件。要编译的最后一个文件“wins”。

这自然会破坏构建。

要求源文件名在项目中全局唯一，实际上非常烦人。您可以更改输出位置，以便它例如包含路径;链接器仍然做正确的事。

Answer 3

我将继续“因为VS是在真空中开发的，来自外部世界的想法通常不会干扰。以这种方式组织构建文件在Visual Studio的第一个版本中可以接受（或者它的非 - 工作室前身），因为这是它总是在内部完成的方式，没有人从外面进来说“你知道，世界其他地方真的想分开中间垃圾文件和他们的实际来源代码“，VS团队从未认定这是一个问题。

这只是猜测，但我想不出更好的解释。

Answer 4

如果您使用Qt Creator作为开发IDE，那么版本2现在默认启用“阴影构建”，它完全按照您描述的方式工作，并且非常有用。

它也是一个打开或关闭的复选框，比Visual Studio稍微复杂一点。

Answer 5

因为当我们聪明地工作时，它们是不必要的。我们始终可以在构建代码之前先提交代码，然后签出到单独的文件夹，然后在第二个位置进行源代码构建。

然后我们可以将构建检入到另一个分支，然后将其检出到另一个位置以运行我们的测试。