I’m currently busy porting a large native C++ project from VS2008 to VS2010 and one of the issues I keep running into was build times. The VS2008 build uses a distributed build system; Unfortunately the vendor doesn’t support VS2010 yet, so I couldn’t use the same infrastructure. In order to get a decent build speed, I started exploring MSBuild’s ability to build projects in parallel (which is fairly similar to VS2008’s ability to build projects in parallel) and the C++ compiler’s ability to make use of multiple processors/cores, aka the /MP switch.

This resulted in a decent speedup in a lot of projects but then I ran into an issue with a few projects in the solution using #import to generate import libraries and smart pointer wrappers for COM components. Unfortunately it turns out that the compiler doesn’t support multiprocessor compiles when the file to be compiled is using #import - which I admittedly didn’t find that surprising, given that the compiler is actually generating a couple of source files when processing #import.

However there is a workaround if your project is using precompiled headers - include the #import statement in the precompiled header. If you’re using no_implementation in the header #import, move the implementation_only #import into the cpp file that triggers the generation of the precompiled header, then remove the #import directives from the other files source files in the project. Just by observing the way projects are built, it seems that the precompiled header is always generated before the rest of the project is built. Of course this makes sense, there is not much of a point of kicking off the compile of other files in the project that need the precompiled header until it has been built. This however means that the compiler deems it safe to use #import inside a precompiled header.

This appears to work around the compiler’s limitation and allows you to use /MP in builds that use #import.