我有一个解决方案，其中包含许多使用PCH的Visual C++项目，但某些项目为满足特定需求打开了特定的编译器开关。
大部分这些项目在其各自的stdafx.h（STL、boost等）中共享相同的头文件集。我想知道是否可能在项目之间共享PCH，以便于不必为每个项目编译每个PCH，而是可以拥有一个通用的PCH，供解决方案中的大多数项目使用。
似乎可以在项目设置中指定PCH的位置作为共享位置，所以我猜这应该可行。我还假设所有使用共享PCH的项目中的所有源文件都必须具有相同的编译器设置，否则编译器将抱怨PCH与正在编译的源文件之间存在不一致。
有人尝试过这个吗？它能行吗？
相关问题：这样的共享PCH应该过度包容吗？或者这会影响总体构建时间吗？例如，共享PCH可以包含许多广泛使用的STL头文件，但某些项目只需要<string>和<vector>。使用共享PCH节省的时间是否需要在后期的构建过程中付出代价，因为优化器必须丢弃PCH带入项目中的所有未使用的内容？
是的，这是可能的，我可以向您保证，节省的时间是显著的。当您编译您的PCH时，您必须从创建PCH文件的项目中复制.pdb和.idb文件。在我的情况下，我有一个简单的两个文件的项目来创建PCH文件。头文件将是您的PCH头文件，源文件则被告知在项目设置中创建PCH——这与您通常在任何项目中所做的类似。正如您提到的，您必须对每个配置使用相同的编译设置，否则会出现差异，编译器会发出警告。
每次重新构建或重新编译PCH时复制上述文件将会很麻烦，因此我们将自动化这个过程。要自动复制，执行一个预构建事件，在其中将上述文件复制到适当的目录。例如，如果您正在编译PCH的Debug和Release版本，则从PCH项目的Debug复制文件到依赖项目的Debug。所以，一个复制命令看起来像这样
copy PchPath\Debug*.pdb Debug\ /-Y
请注意末尾的/-Y。在第一次构建之后，每次后续构建都是增量编译的，因此如果再次替换文件，Visual Studio将会抱怨有损坏的符号。如果它们确实被破坏了，您可以始终执行重新构建，这将再次复制文件（这时不会跳过它们，因为它们已不存在——清理将删除文件）。
希望这能帮到您。我花了很长时间才能做到这一点，但它是值得的。我有几个依赖于一个大型框架的项目，PCH只需要编译一次。所有依赖项目现在都可以很快地进行编译。
编辑：与其他几个人一样，我已经在VS2010和VS2012下对此进行了测试，似乎可以正常运行。
虽然这是一个老问题，但我想给出一个新的答案，适用于Visual Studio 2017，并且不涉及任何复制。唯一的缺点：编辑和继续不再起作用。
基本上，您必须为预编译头文件创建一个新项目，并使所有其他项目依赖于它。以下是我所做的：
步骤如下：
在解决方案中创建一个新项目，其中包括头文件（从这里起称为pch.h）和一个只有一行的cpp文件，该文件包括pch.h。该项目应该创建一个静态库。设置新项目以创建预编译头文件。输出文件需要被所有项目访问。对于我来说，这是相对于IntDir的，但对于默认设置，它可以相对于$(SolutionDir)。pch项目必须只包含所有其他项目也具有的定义。
使所有其他项目依赖于这个新项目。否则，构建顺序可能会出错。
设置所有其他项目使用pch.h。请注意，输出文件参数与pch项目中的参数相同。额外的包含目录也需要指向pch.h目录。您还可以强制在每个cpp中包含pch文件（或者在每个cpp文件的第一行手动包含它）。
我希望我没有忘记任何东西。对于我的解决方案（130k loc，160个项目），这导致编译时间从大约3:30分钟缩短到了约2:30分钟。
Samaursa的回答对我很有帮助。
我也看到了这个链接，它可以工作（在底部找到Reginald的答案）。
这个使用copy，而Reginald的使用xcopy（我更喜欢xcopy）。无论哪种方式，谢谢 - 这大大加快了我的构建速度。
看起来不可能，因为每个源文件都必须针对与预编译头文件编译时相同的PDB进行编译。真糟糕。
