Sharing intermediate files between C++ projects?

Question

I'm currently trying to figure out whether it is possible for two different native Visual-C++ projects (that have exactly the same compiler settings) to share their intermediate files (obj, pch, ...)

An example should help:

This is a normal setup:

PROJECTS \ P1 \ p1.vcproj; p1.cpp; ...
              \ Release_Intermediate_Dir \ p1.obj
                                         \ tool1.obj
         \ P2 \ p2.vcproj; p2.cpp; ...
              \ Release_Intermediate_Dir \ p2.obj
                                         \ tool1.obj
         \ COMMON \ tool1.cpp; ...

What about this setup:

PROJECTS \ P1 \ p1.vcproj (uses: p1.cpp; p1_main.cpp)
              \ p1_test.vcproj (uses: p1.cpp; p1_test.cpp)
              \ Release_Intermediate_Dir \ p1.obj      (used by both projects p1 and test)
                                         \ tool1.obj
                                         \ p1_main.obj (only p1.vcproj)
                                         \ p1_test.obj (only p1_test.vcproj
         \ COMMON \ tool1.cpp; ...

Can I use the same intermediate folder for two C++ projects, thereby sharing the obj files directly?

Or will I always need to have an additional static lib project? (As far as I understand, a static lib is just a container for obj files.)

---

Why would I want to do this? Look at this blog post: Writing Unit Tests in Visual Studio for Native C++.

It uses a static lib for the sole purpose of having two different executables (main functions, if you will). (Forget about the managed/CLI stuff.) This means having 3 projects in your solution (having to maintain three projects), when you really only want two projects that share the same code with the same compilation settings but use a different main/startup rigging.

Answer 1

By enforcing the same compilation flags for both projects and making the intermediates of project A prerequisites of project B, you remove all degrees of freedom from B. There is no conceivable possibility to compile B alone, and your link suggests B has no raison d'etre apart from testing A. The easiest and cleanest solution would be to merge the tests from B into A and make the whole thing one project (which it is, frankly).

In automake parlance, you'd declare the unit tests in B as check_PROGRAMS and they'd only be compiled for checking your program. I'm no Visual-C++ expert, but that's the clean solution and should somehow be doable with VC++.

Addendum: To clarify the automake parlance, a project there would for example look like:

noinst_LTLIBRARIES = libthings-to-test.la libthings-not-tested.la
bin_PROGRAMS = production
check_PROGRAMS = unit_test_a

production_SOURCES = main.cpp
production_LDADD = libthings-to-test.la libthings-not-tested.la
unit_test_a_SOURCES = test.cpp
unit_test_a_LDADD = libthings-to-test.la
libthings_to_test_la_SOURCES = foo.cpp bar.cpp baz.cpp

with the whole codebase (production code, common libraries, tests) in one project, i.e. one unit that is configured and distributed wholly and has a single version number attached. When installed by the end user/distributor, a single program production.exe would be linked. When compiled with make all, the convenience libraries and necessary objects would be compiled in the build directory, and when make check is called, the objects only necessary for unit tests are compiled, the production code linked in and the tests are run. Again, I'm sorry I can't translate this into Microsoft Speak.