0

I have a fairly large multi-project C++ solution in Visual Studio 2015. Some of the projects compile to static libraries which are used by other projects, and most of them use precompiled headers to speed up compilation. Each project also has multiple build configurations: debug, release, and several testing configurations which always build an executable to run the tests (even if the normal configurations build a static library).

When building debug and release configurations, or when doing a full rebuild, everything works well, but when doing an incremental build of a test configuration for a project that uses another project's static library, I get C2859 errors which cause the build to fail.

For example, let's say I have a project peach which builds a static library, and a project cobbler that relies on peach. The precompiled header for cobbler references only system and external libraries (no headers from inside the solution). cobbler's test configuration references peach.lib. peach.lib is created by peach's release configuration, so I have a solution configuration called cobbler-test which specifies that:

  • peach uses its release project configuration
  • cobbler uses its test project configuration.

Building cobbler-test from scratch (or rebuilding it, clean & build, etc) works fine. But if I then modify a source file called crust.cpp in cobbler and try to build, I get this error:

c:\...\cobbler\src\crust.cpp(1): error C2859: C:\...\out\cobbler-test.pdb is not the pdb file that was used when this precompiled header was created, recreate the precompiled header.

Again, this only happens when referencing a static library from the same solution that was built with a project configuration name different from the current one. With both projects using release or debug, incremental builds work fine.

Having to do a full rebuild every time defeats the purpose of using precompiled headers in the first place. Is there any way to get incremental testing configurations to work without having to resort to creating extra project configurations for every combination of projects?

bcrist
  • 1,520
  • 13
  • 25

1 Answers1

0

My current solution to this problem is not to use testing configurations, and to create separate projects for testing projects that generate static libraries. This allows all dependent projects to use the same project configuration and allows the precompiled headers to work their magic without blowing up when doing incremental builds.

While this works fairly well for the static libraries, since they can easily be imported with #pragma comment(lib, ...), it's a bit more problematic for projects that build standalone executables. Thankfully, in my case most of those projects don't have a lot of stuff that needs testing.

bcrist
  • 1,520
  • 13
  • 25