Hi Brad,

Thanks for the feedback.

I've extracted the change to build Windows 8.1 on VS 2015 and submitted it as a 
separate change. Windows 10 support will need to be built on top of the other 
change since they share some of the same code.

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.

I'm not sure if there's a different/better way to handle this case.


-----Original Message-----
From: Brad King [mailto:[email protected]] 
Sent: Monday, August 31, 2015 13:06
To: Gilles Khouzam <[email protected]>
Cc: [email protected]
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 08/30/2015 06:41 PM, Gilles Khouzam wrote:
> http://www.cmake.org/Bug/view.php?id=15670
> Add support for setting "Windows target platform version" in VS2015

Most of your changes look good but I think this issue needs more discussion.  
There is already some discussion in the issue tracker entry linked above.

Your patch checks a VS_DEFAULT_TARGET_PLATFORM_VERSION variable but does not 
document it or explain who/what is supposed to set it.  There is a comment 
about using the latest SDK but right now it looks like the value of that 
variable is used directly.

Having a VS_TARGET_PLATFORM_VERSION target property is convenient for 
customization but should not be the main way to set this value.
The WindowsTargetPlatformVersion value is something that should be set in 
try_compile projects too for consistency.  If we were only cross-compiling then 
having a toolchain file setting would make sense.  However, this should work 
when not cross-compiling too.

On OS X we have CMAKE_OSX_SYSROOT to specify the SDK.  The value is propagated 
by Source/cmCoreTryCompile.cxx into try_compile projects.
It is selected originally by Modules/Platform/Darwin-Initialize.cmake
if not specified by the user.  I think similar infrastructure should be built 
for selecting the Windows SDK.

> As part of this change, I'm also fixing a bug when using VS2015 to 
> target Windows Phone or Windows Store 8.1 without having VS2013
[snip]
> simply to make the desktop detection code be virtual.

Please split the relevant hunks for that part out so they can be committed with 
their own message/explanation.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Reply via email to