[cmake-developers] [Patch] Adding Windows 10 support

[Gilles Khouzam]

Sorry, you are right, try_compile calls do use the generator and don't have a problem. 

I was trying to do something similar to what you are describing here:
> We could simply define a
> 
>  CMAKE_VS_TARGET_PLATFORM_VERSION
> 
> variable that is used to initialize VS_TARGET_PLATFORM_VERSION target properties (see SetPropertyDefault calls in the source).
> Then the generator can look just at the target property.  If not set it should choose a default based on the current host version of Windows as discussed above.  Then we just need to teach cmCoreTryCompile to propagate this
> setting.
> 
> The above-linked issue also mentions that TargetFrameworkVersion may need similar infrastructure.

Perhaps the default selection (at least for Store apps since that's the one that requires the flag) should be the newest SDK less than the version of the host System. If CMAKE_VS_TARGET_PLATFORM_VERSION is specified then we would simply use it.


-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Wednesday, September 2, 2015 08:25
To: Gilles Khouzam <Gilles.Khouzam at microsoft.com>
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/01/2015 05:19 PM, Gilles Khouzam wrote:
> For VS_DEFAULT_TARGET_PLATFORM_VERSION, what I'm trying to achieve is 
> almost an internal property that is used for the try_compile phase. 
> Since the generator is not used in that scenario, the project is using 
> the template from Modules/CompilerId/VS-10.vcxproj.in. In that case, 
> we need to set the tag for the WindowsTargetPlatformVersion. During 
> the generation, I query for the latest SDK version in the 
> GlobalGenerator and set the VS_DEFAULT_TARGET_PLATFORM_VERSION
> property that is then used in CMakeDetermineCompilerId.cmake to set 
> the variable that the template uses in the Windows 10 case.

The generator *is* used for try_compile calls.  The template in Modules/CompilerId/VS-10.vcxproj.in is used *only* for the compiler identification step which occurs before we have enough information to do a full try_compile.  The compiler id step does need special handling to set this value, but it should be based on however the value is determined for the generator normally.

As discussed in http://www.cmake.org/Bug/view.php?id=15670
the SDK for the latest Windows version may not be the proper default choice.  Perhaps it should be the SDK for the host machine's version of Windows to make sure we don't use APIs that cannot run on the current machine.  IIRC this is the default on OS X with CMAKE_OSX_SYSROOT.

Unlike CMAKE_OSX_SYSROOT, which is used by all generators on OS X, the WindowsTargetPlatformVersion value is something only for the VS IDE generators.  In any command-line build we expect the INCLUDE/LIB environment variables to already be set to the proper location.  Therefore we need to define a way to set the WindowsTargetPlatformVersion only for VS IDE generators since they generate the environment in which to run the toolchain.

CMAKE_GENERATOR_TOOLSET and CMAKE_GENERATOR_PLATFORM are existing options with generator-specific behavior.  For VS they set <PlatformToolset> and <Platform>, respectively.
There is quite a bit of C++-side infrastructure to propagate these values to all the right places (and honor cmake -T and -A options on the command line).  I'd rather not have something quite so heavyweight for WindowsTargetPlatformVersion because it is a pretty narrow case that should not need a dedicated command-line option and won't be meaningful to other generators.

We could simply define a

 CMAKE_VS_TARGET_PLATFORM_VERSION

variable that is used to initialize VS_TARGET_PLATFORM_VERSION target properties (see SetPropertyDefault calls in the source).
Then the generator can look just at the target property.  If not set it should choose a default based on the current host version of Windows as discussed above.  Then we just need to teach cmCoreTryCompile to propagate this setting.

The above-linked issue also mentions that TargetFrameworkVersion may need similar infrastructure.

-Brad