[cmake-developers] Specifying VS target platform

[Patrick Gansterer]

On Mon, 17 Sep 2012 09:57:28 -0400, Brad King wrote:
> On 09/14/2012 05:59 PM, Patrick Gansterer wrote:
>> Maybe you can merge the first patch already.
>
> Yes, done.
>
>>> The idea of a "generator platform" is not generic among all 
>>> generators.
>>> Rather than the general CMAKE_GENERATOR_PLATFORM infrastructure I'd
>>> generator-specific handling.  The value of -GP should be passed to 
>>> the
>>> global generator created from -G.  If the generator does not 
>>> support
>>> platform specification in this way then -GP should be an error (all
>>> generators except VS >= 8).  If the generator does support -GP then 
>>> it
>>> should do its own thing to save the value.  For VS save it in a 
>>> cache
>>> entry like "CMAKE_VS_PLATFORM" (we have "CMAKE_VS_PLATFORM_TOOLSET"
>>> already for the VS 10 toolchain in some cases).
>>
>> I'm not a big fan of your ideas: What about the parts where we
>> pass the generator platform to other parts? Do we want to add
>> branches for every generator type to get get correct value for
>> the -GP parameter (e.g. if (CMAKE_GENERATOR == "Visual Studio
>> ...") "-GP ${CMAKE_VS_PLATFORM}")? IMHO that's not a good
>> idea. Also handling for making sure that generator platform
>> isn't changed by the user (like we do for -G already) in a
>> second run of CMake must be duplicated later if we add -GP to
>> more than one generator. (and so on...)
>
> Good points, but we still need to reject -GP when using generators
> for which it does not make sense.  I think it may be moot anyway;
> see below.
>
>>> I realized that existing projects may test ${CMAKE_GENERATOR} to 
>>> look
>>> for things like "Win64".  For compatibility we need to make sure 
>>> that
>>>
>>> -G "Visual Studio 10" -GP x64
>>>
>>> results in CMAKE_GENERATOR being set to
>>>
>>> -G "Visual Studio 10 Win64"
>>>
>>> while processing CMake code even if it is not used that way
>>> internally.  Of course for future VS versions the generator names
>>> will not need to work this way, only the existing ones.
>>
>> Since we need to support -G "Visual Studio 10 Win64" anyway, I don't 
>> see
>> much problem if such cases will work with -G "Visual Studio 10 
>> Win64",
>> but not with -G "Visual Studio 10" -GP x64.
>
> We are talking about changing the way the user selects the generator
> in the GUI to be equivalent to -G/-GP.  We cannot process existing
> projects differently depending on how the generator was selected.
>
> I also know there are projects that pass ${CMAKE_GENERATOR} to
> internal invocations of CMake in order to say "build it like I'm
> built".  These paths would not work if any information moved over
> to CMAKE_GENERATOR_PLATFORM or an equivalent variable.
>
> I think the value of -GP has to be stored in CMAKE_GENERATOR at
> the end of the generator name as it is now.  The new option and GUI
> updates are really just about simplifying the selection of the
> generator and avoiding per-platform global generators in the internal
> implementation.  Users can either use -G and specify the full
> generator name with platform or use -G/-GP separately but either way
> the value of CMAKE_GENERATOR will be the same.
>
> This can probably be improved in the future with a new cmake policy
> but I don't want to open that can of worms just for WinCE.  I think
> you can implement -G/-GP such that the values are both stored in the
> CMAKE_GENERATOR value.  Internally we won't need a separate global
> generator for every platform anymore, but that does not change the
> public interface.

If we store everything in one variable (via string concatenation) I 
don't see much value in an extra -GP switch. We need to split the 
${CMAKE_GENERATOR} variable into generator+platform then all the time 
anyway.
Maybe we can only change to current exact match of the generator name 
to a "startsWith" and let the global generator class decide if the 
generator name is valid?

-- Patrick