On Fri, Jun 05, 2009 at 10:17:43PM -0400, Philip Lowman wrote: > How would you handle target_link_libraries() and, ultimately, > find_library()? Most people using VS that would want this feature added > probably already have many of their dependencies setup with find_package() > and/or find_library().
target_link_libraries() already has a hack or two that will help: the debug/optimized keywords (which are apparently deprecated in favor of...), and add_library(IMPORTED). Perhaps some additional parameters are needed (win32/x64 alongside debug/optimized, or IMPORTED_WIN32_LOCATION/IMPORTED_WIN64_LOCATION in addition to IMPORTED_LOCATION). find_library() might be workable with clever use of PATHS or HINTS (C:\libfoo\$(PlatformName)\lib, where $(PlatformName) is whatever VS macro points to either win32 or x64)? Is it a common practice to have 32-bit and 64-bit libraries sitting in the same path and differentiated only by filename? I haven't seen much of this. > I guess I'm not a big fan of this idea, not because I don't think it might > be beneficial, but just because it goes against the CMake design which has > always been "one compiler at a time" and I think would be hard and/or hacky > to implement. I agree from a philosophical standpoint, but I can tell you that Visual Studio developers are very used to having this 32-bit/64-bit cross compile behavior at their fingertips. > Instead, how about retrofitting CMake gui with tabs each of which is a build > configuration/build directory. The user could choose which generators he > wants on initial configure via dialog box (similar to how it is now) but > click a big "configure all" button which kicks off n threads and runs > configure on all of the tabs creating multiple build directories for each > configuration. If there are any issues, he could dive into each individual > build configuration and modify things. The "generate all" button wouldn't > work until all build trees have no more modified variables. As you noted, this would be handy (I often have separate debug and release Makefile-based builds that would be nice to configure at the same time) but I think the "separate VS window" or "switch solution file" workarounds are still going to be a bother for VS devs. tyler _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
