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

[Tyler Roscoe]

I already sent a few comments after Philip's reply to this mail. As a
CMake novice I'm not sure I'm the best person to be involved in this
discussion but I guess I'll give it a shot :).

On Fri, Jun 05, 2009 at 01:13:50PM -0400, David Cole wrote:
> platforms. Granted, there are several things to consider in a re-design that
> would allow extending to platform-organized sln/vcproj files... but I think
> it would be better in the long run than simply adding new CMake generators
> every time somebody wants a new architecture in a Visual Studio project.

Agreed.

Btw note that VS Express apparently cannot support cross-compiling, so
that introduces another small wrinkle since the VS generator would have
to be different from the VS Express generator.

> The main issue is TRY_COMPILE results. They will be different for different
> architectures. Of course, strictly speaking, you could construct try_compile
> calls that give you one result in a Debug build and another in a Release
> build, right now. (Different build time configs may results in different
> results...) So.... really try_compile needs to be avoided or somehow account
> for different configs and platforms for a project to work as expected after
> being configured by CMake. (Iterating over all generated configs/platforms
> and storing separate results keyed by config and platform would be one
> approach...)

This is also interesting.

As a workaround, does anyone know if it's possible to let CMake generate
a .vcproj for each generator (win32, x64, wince, whatever) as it does
today, then combining those .vcproj together at the end? The .vcproj are
just XML, and from a cursory investigation it looks like the only things
that a combining script would need to do is merge the <Platforms> and
<Configurations> sections, and hopefully Visual Studio could handle the
rest?

This is obviously a bit hacky, but it could work well with Philip's
proposal about a "multi-tabbed" CMake GUI, and it might get some of our
developers off our backs until a more complete redesign could be
completed :). 

David I'm still happy to open an issue in the tracker, though it looks
like we have more to iron out before something meaningful can be entered
as a feature request.

tyler