[CMake] Visual Studio Release / Debug with different link dependencies?

Gregory Peele ARA/CFD gpeele at ara.com
Wed Jan 6 16:58:12 EST 2010

Hi all,

While I'm hitting this list today I want to ask a question about dealing with multiple build configurations in Visual Studio with badly behaved third-party libraries.

I would like to be able - in the same binary directory / generated Solution - to build both Debug and Release builds of my project.  Some of the targets in my project depend on third-party libraries that absolutely must be linked to the same MSVRT as my project due to misuse of memory resources.  This implies that my target has to have different TARGET_LINK_LIBRARIES settings for Release and Debug, but the configuration choice is not made until we are in the VS IDE, long after CMake has generated the project.  There are also reasons this is desirable even when not strictly required by bad behavior of the third-party library.

It's easy enough to update Find scripts to find both debug and release settings of the same library (a la OpenSceneGraph or Qt) and our third-party directory structure would support that, but I have no idea if it's possible to specify configuration-specific link dependencies for Visual Studio that are correctly honored in the IDE.

Right now we have separate binary directories for Release and Debug builds of the project.   It works, but this greatly frustrates those on our team who are accustomed to Visual Studio workflow in a single Solution - of course, me being historically a Linux developer I didn't think anything of it.  It also means that the Debug configuration in the Release binary directory produces broken code, and vice-versa, which frequently costs us about 30 minutes when we accidentally build the wrong configuration without noticing because the IDE always defaults to Debug after project generation.

Any thoughts?

Gregory Peele, Jr.
Applied Research Associates, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100106/e9c66d4b/attachment.htm>

More information about the CMake mailing list