On Mon, Jun 8, 2009 at 9:43 AM, Tyler Roscoe <[email protected]> wrote:
> 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 shudder to think of having to multiply all of my find_library calls with architecture dependent versions: Say goodbye to PROJECT_LIBRARY, say hello to PROJECT_LIBRARY_ARCH32 and PROJECT_LIBRARY_ARCH64. There are many places in my code where I have switches based on 32 or 64 bit architectures. All of that machinery will have to reimplemented. James
_______________________________________________ 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
