在 Visual Studio 中的项目之间共享预编译头文件
我有一个包含许多 Visual C++ 项目的解决方案，所有项目都使用 PCH，但有些项目针对特定项目的需要打开了特定的编译器开关.
I have a solution with many Visual C++ projects, all using PCH, but some have particular compiler switches turned on for project-specific needs.
这些项目中的大多数在各自的 stdafx.h(STL、boost 等)中共享同一组头文件.我想知道是否可以在项目之间共享 PCH，这样我就不必为每个项目编译每个 PCH，我可以拥有一个解决方案中的大多数项目都可以使用的通用 PCH.
Most of these projects share the same set of headers in their respective stdafx.h (STL, boost, etc). I'm wondering if it's possible to share PCH between projects, so that instead of compiling every PCH per-project I could maybe have one common PCH that most projects in the solution could just use.
似乎可以在项目设置中将 PCH 的位置指定为共享位置，所以我有预感这可以工作.我还假设所有使用共享 PCH 的项目中的所有源文件都必须具有相同的编译器设置，否则编译器会抱怨 PCH 和正在编译的源文件之间的不一致.
It seems possible to specify the location of the PCH as a shared location in the project settings, so I have a hunch this could work. I'm also assuming that all source files in all projects that use a shared PCH would have to have the same compiler settings, or else the compiler would complain about inconsistencies between the PCH and the source file being compiled.
有人试过吗?有用吗?
一个相关的问题:这样的分片 PCH 是否应该过于包容，还是会影响整体构建时间?例如，一个共享的 PCH 可能包含许多广泛使用的 STL 标头，但某些项目可能只需要
A related question: should such a shard PCH be overly inclusive, or would that hurt overall build time? For example, a shared PCH could include many STL headers that are widely used, but some projecst might only need <string> and <vector>. Would the time saved by using a shared PCH have to be paid back at a later point in the build process when the optimizer would have to discard all the unused stuff dragged into the project by the PCH?
推荐答案
是的，我可以向您保证，节省的时间非常重要.编译 PCH 时，必须从创建 PCH 文件的项目中复制 .pdb 和 .idb 文件.就我而言，我有一个简单的两个文件项目，用于创建 PCH 文件.标题将是您的 PCH 标题，并且源将被告知在项目设置下创建 PCH - 这类似于您在任何项目中通常会做的事情.正如您所提到的，您必须为每个配置设置相同的编译设置，否则会出现差异并且编译器会抱怨.
Yes it is possible and I can assure you, the time savings are significant. When you compile your PCH, you have to copy the .pdb and .idb files from the project that is creating the PCH file. In my case, I have a simple two file project that is creating a PCH file. The header will be your PCH header and the source will be told to create the PCH under project settings - this is similar to what you would do normally in any project. As you mentioned, you have to have the same compile settings for each configuration otherwise a discrepancy will arise and the compiler will complain.
每次重建或每次重新编译 PCH 时都复制上述文件会很痛苦，因此我们将其自动化.要自动复制，请执行预构建事件，将上述文件复制到适当的目录.例如，如果您正在编译 PCH 的 Debug 和 Release 构建，请将 PCH 项目的 Debug 中的文件复制到依赖项目的调试.所以复制命令看起来像这样
Copying the above mentioned files every time there is a rebuild or every time the PCH is recompiled is going to be a pain, so we will automate it. To automate copying, perform a pre-build event where the above mentioned files are copied over to the appropriate directory. For example, if you are compiling Debug and Release builds of your PCH, copy the files from Debug of your PCH project over to your dependent project's Debug. So a copy command would look like this
复制 PchPathDebug*.pdb Debug/-Y
copy PchPathDebug*.pdb Debug /-Y
注意末尾的 /-Y.第一次构建后，每个后续构建都会增量编译，因此如果再次替换文件，Visual Studio 会抱怨符号损坏.如果它们确实被损坏了，你总是可以执行重建，这将再次复制文件(这次它不会跳过它们，因为它们不再存在――清理会删除文件).
Note the /-Y at the end. After the first build, each subsequent build is incrementally compiled, therefore if you replace the files again, Visual Studio will complain about corrupted symbols. If they do get corrupted, you can always perform a rebuild, which will copy the files again (this time it won't skip them as they no longer exist - the cleanup deletes the files).
我希望这会有所帮助.我花了很长时间才能够做到这一点，但这是值得的.我有几个项目依赖于一个大框架，而且 PCH 只需要编译一次.现在所有依赖项目的编译速度都非常快.
I hope this helps. It took me quite some time to be able to do this, but it was worth it. I have several projects that depend on one big framework, and the PCH needs to be compiled only once. All the dependent projects now compile very quickly.
与其他几个人一起，我在 VS2010 下测试了这个和 VS2012 并且它似乎可以正常工作.
Along with several other people, I have tested this under VS2010 and VS2012 and it does appear to work properly.
相关文章