[CMake] [VS gen] Multiple configurations code

[David Cole]

On Mon, Jul 26, 2010 at 3:12 PM, John Drescher <drescherjm at gmail.com> wrote:

> On Mon, Jul 26, 2010 at 3:03 PM, Olaf van der Spek <olafvdspek at gmail.com>
> wrote:
> > On Mon, Jul 26, 2010 at 9:00 PM, John Drescher <drescherjm at gmail.com>
> wrote:
> >> You need to add variables and such. I believe that is done in
> windows-cl.cmake
> >
> > I'd like to generate both dynamic and static, x86 and x64 configs.
> > CMake already knows how to build those, so it's not about adding
> > variables for those.
> >
>
> I believe you still need to fill in the details for the new
> configurations. Here is part of Windows-cl.cmake
>
> SET (CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR")
> SET (CMAKE_CXX_FLAGS_DEBUG_INIT "/D_DEBUG /MDd /Zi /Ob0 /Od /RTC1")
> SET (CMAKE_CXX_FLAGS_MINSIZEREL_INIT "/MD /O1 /Ob1 /D NDEBUG")
> SET (CMAKE_CXX_FLAGS_RELEASE_INIT "/MD /O2 /Ob2 /D NDEBUG")
> SET (CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT "/MD /Zi /O2 /Ob1 /D NDEBUG")
>
> As for 64bit / 32 bit I do not think this is a simple modification to
> allow 64bit and be 100% correct.
>
>
Olaf,

It's definitely not easy to make such a modification with the current VS
generators. For better or for worse, there are currently separate generators
for Visual Studio 32-bit and 64-bit projects. It would be a major re-working
of those separate generators to combine them into a single one that chose
the architecture at *build* time rather than at configure time.

Many projects already have logic in their CMakeLists.txt files that goes
something like this:
if(CMAKE_SIZEOF_VOID_P EQUAL 8)
  # do 64-bit stuff at *configure* time...
else()
  # 32-bit stuff
endif()

If you make *configure* time decisions based on architecture, then it's not
easy to support multiple architectures without multiple configures.
(Multiple build trees...)

Since this is a prevalent scheme that is widely used by folks coming from
single-config, single-architecture (makefile based) build systems... it's
the way CMake has gotten to the point it's at now. I'm not saying this is
good or bad, just explaining that this is the way it is, and that there are
historical reasons why we got to this point.

So.... what you're attempting is probably possible, but it's definitely not
easy. And it will probably require some significant re-work of the existing
code.

Let us know if you have any other specific questions that we can answer for
you.


Hope this helps,
David Cole
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100726/1f16b165/attachment.htm>