[CMake] [VS gen] Multiple configurations code

[David Cole]

On Mon, Jul 26, 2010 at 3:46 PM, Olaf van der Spek <olafvdspek at gmail.com>wrote:

> On Mon, Jul 26, 2010 at 9:21 PM, David Cole <david.cole at kitware.com>
> wrote:
> > 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.
>
> Why are there two generators?
> I don't see why the decision has to be made at another time.
> Configure time is fine with me.
>

Maybe I'm misinterpreting what you're asking. I thought you said you wanted
x86 and x64 both in the same build tree. That would be not making a choice
at configure time, and deferring the choice of arch to build time. But with
CMake as is, it is typically a configure time choice in most projects.

As to why there are two generators, I don't understand the precise decisions
behind having it done it that way. Perhaps if somebody else knows, they will
chime in. (I've lamented this fact before when folks have asked about adding
config types for various phone- OSes...)


> > 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...)
>
> Is there a problem with multiple configures / build trees?
>

No, not at all. We do this all the time. But again, I thought from your
questions that you were trying to do it all in one build tree.


>
> > 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.
>
> x64 is not a priority for me ATM.
> Having static configs (static lib, static runtime and static lib,
> dynamic runtime) is more important.
>
> Olaf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100726/5a8aa0b2/attachment-0001.htm>