Can't build both Debug and Release in same build directory on Windows

[sherm1]

(Still testing @mwoehlke-kitware's #1884 changes.) Using an out-of-source build directory, I built the drake-superbuild.sln using the Debug configuration in VS 2015 (ALL_BUILD target). Then I went to drake/drake.sln, built ALL_BUILD as Debug, and successfully ran some examples in the debugger.

Then I went back to drake-superbild.sln, switched to Release and did ALL_BUILD again. Completed successfully. Back to drake/drake.sln, ALL_BUILD as Release, all the (non-Matlab) tests passed.

Staying in that solution, I switched back to the Debug config. Tried to run a test and it crashed. Decided to do an ALL_BUILD Debug, and that failed with:

BulletCollision.lib(btDefaultCollisionConfiguration.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in DrakeCollision.obj
17>BulletCollision.lib(btDefaultCollisionConfiguration.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in DrakeCollision.obj
17>BulletCollision.lib(btDbvtBroadphase.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in DrakeCollision.obj
17>BulletCollision.lib(btDbvtBroadphase.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in DrakeCollision.obj
1

indicating that it was using Bullet's Release libraries when trying to build Debug.

So apparently the superbuild Debug and Release configurations can't exist in the same build directory. If they could then working in drake.sln one could switch back and forth between Debug and Release without rebuilding or leaving Visual Studio, which is the usual workflow there. I'm guessing that means something in the superbuild output wasn't put into a configuration subdirectory (Debug/ or Release/ e.g.). Please fix if possible.

[sherm1]

This is likely related to #2046.

[mwoehlke-kitware]

AFAICT, bullet is overwriting its installed libraries depending on which build last believes that it needs to run bullet's install step. There isn't an easy fix for this, and based on conversation with @billhoffman, we actually introduced this problem because the (easy) alternative was broken even worse.

I don't think a short term "proper" fix is going to be practical; at best, it likely requires purging all use of pkg-config (#2483) and using CMake exported/imported targets instead (definitely for bullet, possibly for all dependencies). A better short term solution is "don't do that"; it should be possible at this point to have separate build directories for debug and release (and if not, fixing the remaining problems there is likely more feasible in the short term, and will also have wider reaching benefit).

[sherm1]

I've been using separate build directories for Debug and Release. That seems to be a reasonable workaround. The remaining problem is that running the tests (even from within Visual Studio) requires that the PATH be set correctly for the DLL's to be found. They should be using whatever libraries just got built and not depending on PATH. I'll file a separate issue and close this one.

[mwoehlke-kitware]

The remaining problem is that running the tests (even from within Visual Studio) requires that the PATH be set correctly for the DLL's to be found. They should be using whatever libraries just got built and not depending on PATH. I'll file a separate issue and close this one.

Pedantically, the only way to enforce that is with RPATH, which doesn't exist on Windows. (Practically, on Windows — which doesn't use separate paths for binaries and libraries, and implicitly places . in %PATH% — the installed tests and corresponding libraries should be in the same folder. Generally speaking, .dll's should be installed to bin. Fixing that likely is sufficient for this purpose.)