[CMake] [VS gen] Multiple configurations code

Michael Jackson mike.jackson at bluequartz.net
Mon Jul 26 16:05:39 EDT 2010


On Jul 26, 2010, at 3:46 PM, Olaf van der Spek 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.
>
>> 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, which is what is done now, just at a "higher" level than you are  
wanting. You would like to have Win32 and Win64 in the same solution  
file which would require multiple configure runs in the same build  
directory. Currently CMake requires the developer to create 2 distinct  
build trees, one for Win32 and one for Win64 where each build  
directory is configured with the appropriate compiler version. So same  
idea just implemented slightly differently.

>
>> 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

     It may not be a priority for _you_ but it is a requirement for  
me. The code snippet that David C. put in there is extremely important  
to get right and the ONLY way to get it right is to run configure  
multiple times for each Arch. Just have a look at any project that  
attempts to support Universal Binaries on OS X. The same problem  
exists. One has to make sure that the sizes of pointers and some  
primitives are correct so header file generation is correct.



More information about the CMake mailing list