On Mon, Jun 8, 2009 at 9:43 AM, Tyler Roscoe <span dir="ltr"><<a href="mailto:tyler@cryptio.net">tyler@cryptio.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Fri, Jun 05, 2009 at 10:17:43PM -0400, Philip Lowman wrote:<br>
> How would you handle target_link_libraries() and, ultimately,<br>
> find_library()? Most people using VS that would want this feature added<br>
> probably already have many of their dependencies setup with find_package()<br>
> and/or find_library().<br>
<br>
</div>target_link_libraries() already has a hack or two that will help: the<br>
debug/optimized keywords (which are apparently deprecated in favor<br>
of...), and add_library(IMPORTED). Perhaps some additional parameters<br>
are needed (win32/x64 alongside debug/optimized, or<br>
IMPORTED_WIN32_LOCATION/IMPORTED_WIN64_LOCATION in addition to<br>
IMPORTED_LOCATION).<br>
<br>
find_library() might be workable with clever use of PATHS or HINTS<br>
(C:\libfoo\$(PlatformName)\lib, where $(PlatformName) is whatever VS<br>
macro points to either win32 or x64)? Is it a common practice to have<br>
32-bit and 64-bit libraries sitting in the same path and differentiated<br>
only by filename? I haven't seen much of this.</blockquote><div><br>I shudder to think of having to multiply all of my find_library calls with architecture dependent versions:<br><br>Say goodbye to PROJECT_LIBRARY, say hello to PROJECT_LIBRARY_ARCH32 and PROJECT_LIBRARY_ARCH64.<br>
<br>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.<br><br>James<br></div></div><br>