On Wednesday 13 August 2008 15:55:32 Philip Lowman wrote: > On Wed, Aug 13, 2008 at 3:50 AM, Yuri V. Timenkov > > <[EMAIL PROTECTED]>wrote: > > Why not find two libraries always and and then use > > set(${module_uc}_LIBRARY debug ${module_uc}_LIBRARY_DEBUG optimized > > ${module_uc}_LIBRARY_RELEASE) > > This way CMake will use proper libraries for debug and release modes in > > studio. > > Finding two libraries would certainly be the simplest approach. The short > answer to why I would prefer not to do this > > 1. It's safe to search for "osgd" and then fallback on "osg" for the > _LIBRARY_DEBUG find_library() call on most platforms, but not on MSVC. Yes, therefore I suggest find both libraries anyways. Also, I have a deals with project which produce different class signatures for debug and release modes even on Linux, so debug libraries just won't link with sources compiled with NDEBUG flag.
> On > MSVC if the user links against "osg.lib" with a debug build the only > indication they'll get that things aren't working is when they go to run > their debug executable and it instantly crashes. But it is better to prevent user from doing this and don't let compile code which will crash. This may be a big problem for newcomers or people which rarely change their build configuration. > This is exactly what will happen if they don't have the debug libraries installed. > > 2. I see no reason to clutter the cache with additional _LIBRARY_DEBUG > variables if the user doesn't desire them. Usually, you should mark them as advanced, and write CMakeFiles in the way that user doesn't have to turn Advanced mode on (I suppose you do, because asking such questions). Also, cmake-gui provides good filter to find necessary variables. Usually, user shouldn't alter variables filled with find_* commands. > > The compromise of setting *_LIBRARY_DEBUG to *_LIBRARY unless the user > needs to selectively link against debug libraries seems to be a reasonable > one to me (otherwise it greatly complicates TARGET_LINK_LIBRARIES()) Look at FindBoost.cmake in 2.6 version. This file now became reference on how to deal with static/dynamic/release/debug modes. > > I can have a control variable that determines whether or not these DEBUG > variables are created in the cache, I just can't find an easy way to delete > them if the user changes their mind after initial configure. I provided way which should work. To make find_library search again, you just have to set its value to NOTFOUND, not necessarily delete from cache. One internal variable which is not visible in cache at all is not a problem, CMake uses dozens of them internally (look into CMakeCache.txt). _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake