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

[Tyler Roscoe]

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