[CMake] Creating one Visual Studio solution for many configurations and platforms

James Bigler jamesbigler at gmail.com
Mon Jun 8 11:55:13 EDT 2009


On Mon, Jun 8, 2009 at 9:43 AM, Tyler Roscoe <tyler at cryptio.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090608/f6d7d8b0/attachment.htm>


More information about the CMake mailing list