Re: [cmake-developers] [Patch] Adding Windows 10 support
On 10/01/2015 09:04 AM, Brad King wrote:
> Looks good, thanks. I've applied the series with minor tweaks:
After a C++98 compilation fix and some documentation updates,
this is now in 'master':
Help: Improve CMAKE_SYSTEM_{NAME,VERSION} variable documentation
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70688609
Allow CMAKE_SYSTEM_VERSION to be set without CMAKE_SYSTEM_NAME
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b31ac171
cmSystemTools: Add VersionCompareGreater helper
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61c472a2
VS: Add hook to initialize Windows platform settings
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5dfc4c5f
VS: Add support for selecting the Windows 10 SDK (#15670)
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f077996
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
Re: [cmake-developers] [Patch] Adding Windows 10 support
On 09/30/2015 05:05 PM, Gilles Khouzam wrote: > simply use the SystemVersion to determine the version of > the Windows 10 SDK to use. > > Now, by default on Windows 10 host devices with Visual Studio 2015, > the latest SDK will be used. Looks good, thanks. I've applied the series with minor tweaks: cmSystemTools: Add VersionCompareGreater helper https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ebdf64d Allow CMAKE_SYSTEM_VERSION to be set without CMAKE_SYSTEM_NAME https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6653b235 VS: Add hook to initialize Windows platform settings https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b6b35d0b VS: Add support for selecting the Windows 10 SDK https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=45c06c1d Please test to make sure it all works for you still. 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
Hi Brad, I've changed the code of the 3rd patch to remove the WINDOWS_TARGET_PLATFORM_VERSION and CMAKE_WINDOWS_TARGET_PLATFORM_VERSION and simply use the SystemVersion to determine the version of the Windows 10 SDK to use. Now, by default on Windows 10 host devices with Visual Studio 2015, the latest SDK will be used. I've also changed the sorting of the SDKs and comparison checks to use cmSystemTools::VersionCompare. -Original Message- From: Gilles Khouzam Sent: Monday, September 28, 2015 14:35 To: Brad King Cc: cmake-developers@cmake.org Subject: RE: [cmake-developers] [Patch] Adding Windows 10 support The more I think about it, the more this makes sense and should work out well. Let me take your current changes and adapt them for this and test them out. -Original Message- From: Gilles Khouzam Sent: Friday, September 25, 2015 14:55 To: 'Brad King' Cc: cmake-developers@cmake.org Subject: RE: [cmake-developers] [Patch] Adding Windows 10 support You're right, by targeting another version (8.1 or 6.3), the tag would not be written. Leveraging CMAKE_SYSTEM_VERSION is an interesting idea. Let me mull it over a little bit more and see how I would apply to newer SDKs as they come out, as I would like to minimize the required changes to CMake to support things when they come out (I'm gathering some information on that). -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Friday, September 25, 2015 11:53 To: Gilles Khouzam Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/25/2015 01:00 PM, Gilles Khouzam wrote: > This was done deliberately to only force a value for > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION With the approach in my patch that variable is never set by the generator. It chooses a WindowsTargetPlatformVersion value and reports it in CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION. The CMAKE_WINDOWS_TARGET_PLATFORM_VERSION variable is only for the user-defined selection. > when the CMAKE_SYSTEM_VERSION is specified as 10.0. > Otherwise any Windows 10 machine will use the Windows 10 SDK and not > the Windows 8.1 SDK Why is it wrong to target the host's version by default? This is commonly done on other platforms. If one is building only for the current host this makes sense. If one is building for deployment then extra care is needed anyway. > and I'm not sure that there is a way then target the Windows 8.1 SDK. If one wants to build on a Windows 10 host but target an older version of Windows, one can simply do -DCMAKE_SYSTEM_VERSION=6.3 for example. This is thanks to your patch that allows it to be set separately from CMAKE_SYSTEM_NAME. Actually, why do we need a separate setting like CMAKE_WINDOWS_TARGET_PLATFORM_VERSION to select this at all? Why not just take the highest available SDK that does not exceed CMAKE_SYSTEM_VERSION? CMAKE_SYSTEM_VERSION is meant exactly to specify the target OS version. You posted something about this here: https://cmake.org/Bug/view.php?id=15670#c39247 but I do not quite understand it. Thanks, -Brad 0003-VS-Add-support-for-selecting-the-Windows-10-SDK.PATCH Description: 0003-VS-Add-support-for-selecting-the-Windows-10-SDK.PATCH -- 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
The more I think about it, the more this makes sense and should work out well. Let me take your current changes and adapt them for this and test them out. -Original Message- From: Gilles Khouzam Sent: Friday, September 25, 2015 14:55 To: 'Brad King' Cc: cmake-developers@cmake.org Subject: RE: [cmake-developers] [Patch] Adding Windows 10 support You're right, by targeting another version (8.1 or 6.3), the tag would not be written. Leveraging CMAKE_SYSTEM_VERSION is an interesting idea. Let me mull it over a little bit more and see how I would apply to newer SDKs as they come out, as I would like to minimize the required changes to CMake to support things when they come out (I'm gathering some information on that). -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Friday, September 25, 2015 11:53 To: Gilles Khouzam Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/25/2015 01:00 PM, Gilles Khouzam wrote: > This was done deliberately to only force a value for > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION With the approach in my patch that variable is never set by the generator. It chooses a WindowsTargetPlatformVersion value and reports it in CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION. The CMAKE_WINDOWS_TARGET_PLATFORM_VERSION variable is only for the user-defined selection. > when the CMAKE_SYSTEM_VERSION is specified as 10.0. > Otherwise any Windows 10 machine will use the Windows 10 SDK and not > the Windows 8.1 SDK Why is it wrong to target the host's version by default? This is commonly done on other platforms. If one is building only for the current host this makes sense. If one is building for deployment then extra care is needed anyway. > and I'm not sure that there is a way then target the Windows 8.1 SDK. If one wants to build on a Windows 10 host but target an older version of Windows, one can simply do -DCMAKE_SYSTEM_VERSION=6.3 for example. This is thanks to your patch that allows it to be set separately from CMAKE_SYSTEM_NAME. Actually, why do we need a separate setting like CMAKE_WINDOWS_TARGET_PLATFORM_VERSION to select this at all? Why not just take the highest available SDK that does not exceed CMAKE_SYSTEM_VERSION? CMAKE_SYSTEM_VERSION is meant exactly to specify the target OS version. You posted something about this here: https://cmake.org/Bug/view.php?id=15670#c39247 but I do not quite understand it. 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
You're right, by targeting another version (8.1 or 6.3), the tag would not be written. Leveraging CMAKE_SYSTEM_VERSION is an interesting idea. Let me mull it over a little bit more and see how I would apply to newer SDKs as they come out, as I would like to minimize the required changes to CMake to support things when they come out (I'm gathering some information on that). -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Friday, September 25, 2015 11:53 To: Gilles Khouzam Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/25/2015 01:00 PM, Gilles Khouzam wrote: > This was done deliberately to only force a value for > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION With the approach in my patch that variable is never set by the generator. It chooses a WindowsTargetPlatformVersion value and reports it in CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION. The CMAKE_WINDOWS_TARGET_PLATFORM_VERSION variable is only for the user-defined selection. > when the CMAKE_SYSTEM_VERSION is specified as 10.0. > Otherwise any Windows 10 machine will use the Windows 10 SDK and not > the Windows 8.1 SDK Why is it wrong to target the host's version by default? This is commonly done on other platforms. If one is building only for the current host this makes sense. If one is building for deployment then extra care is needed anyway. > and I'm not sure that there is a way then target the Windows 8.1 SDK. If one wants to build on a Windows 10 host but target an older version of Windows, one can simply do -DCMAKE_SYSTEM_VERSION=6.3 for example. This is thanks to your patch that allows it to be set separately from CMAKE_SYSTEM_NAME. Actually, why do we need a separate setting like CMAKE_WINDOWS_TARGET_PLATFORM_VERSION to select this at all? Why not just take the highest available SDK that does not exceed CMAKE_SYSTEM_VERSION? CMAKE_SYSTEM_VERSION is meant exactly to specify the target OS version. You posted something about this here: https://cmake.org/Bug/view.php?id=15670#c39247 but I do not quite understand it. 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
On 09/25/2015 01:00 PM, Gilles Khouzam wrote: > This was done deliberately to only force a value for > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION With the approach in my patch that variable is never set by the generator. It chooses a WindowsTargetPlatformVersion value and reports it in CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION. The CMAKE_WINDOWS_TARGET_PLATFORM_VERSION variable is only for the user-defined selection. > when the CMAKE_SYSTEM_VERSION is specified as 10.0. > Otherwise any Windows 10 machine will use the Windows 10 SDK > and not the Windows 8.1 SDK Why is it wrong to target the host's version by default? This is commonly done on other platforms. If one is building only for the current host this makes sense. If one is building for deployment then extra care is needed anyway. > and I'm not sure that there is a way then target the Windows 8.1 SDK. If one wants to build on a Windows 10 host but target an older version of Windows, one can simply do -DCMAKE_SYSTEM_VERSION=6.3 for example. This is thanks to your patch that allows it to be set separately from CMAKE_SYSTEM_NAME. Actually, why do we need a separate setting like CMAKE_WINDOWS_TARGET_PLATFORM_VERSION to select this at all? Why not just take the highest available SDK that does not exceed CMAKE_SYSTEM_VERSION? CMAKE_SYSTEM_VERSION is meant exactly to specify the target OS version. You posted something about this here: https://cmake.org/Bug/view.php?id=15670#c39247 but I do not quite understand it. 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
Thanks for the refactor Brad, The patches make sense. >After your change to add a third component to CMAKE_HOST_SYSTEM_VERSION the >value of CMAKE_SYSTEM_VERSION on a Windows 10 host may have a third component. >Therefore we should check that the version starts with "10.0" rather than is >exactly this version. Actually perhaps we should use >cmSystemTools::VersionCompare to do actual integer version component checks. This was done deliberately to only force a value for CMAKE_WINDOWS_TARGET_PLATFORM_VERSION when the CMAKE_SYSTEM_VERSION is specified as 10.0. Otherwise any Windows 10 machine will use the Windows 10 SDK and not the Windows 8.1 SDK and I'm not sure that there is a way then target the Windows 8.1 SDK. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Thursday, September 24, 2015 13:35 To: Gilles Khouzam Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/23/2015 06:48 PM, Gilles Khouzam wrote: > This adds only the WINDOWS_TARGET_PLATFORM_VERSION property as it > currently only supports the desktop scenario and is extracted from the > rest of the Windows 10 Store support. Thanks. While reviewing this much simpler patch I realized that the WindowsTargetPlatformVersion is more like PlatformToolset than I previously thought. This led me to another design, perhaps closer to one of your earlier patches, in which the VS 2015+ generators select the WindowsTargetPlatformVersion up front based either on CMAKE_WINDOWS_TARGET_PLATFORM_VERSION or on a computed default. Either way we should set CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION to report the selection to CMakeDetermineCompilerId for use in "CompilerId/VS-10.vcxproj.in". For now I decided to leave out support for per-target WINDOWS_TARGET_PLATFORM_VERSION properties. While testing these changes I found a bug that I've now fixed: cmCoreTryCompile: Fix internal argument vector construction http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=710bde43 Please try out the attached patches based on that version. Then provide fixup patches based on the comments below if needed. > If CMAKE_SYSTEM_VERSION is set to 10.0 then After your change to add a third component to CMAKE_HOST_SYSTEM_VERSION the value of CMAKE_SYSTEM_VERSION on a Windows 10 host may have a third component. Therefore we should check that the version starts with "10.0" rather than is exactly this version. Actually perhaps we should use cmSystemTools::VersionCompare to do actual integer version component checks. > the latest Windows 10 SDK but not more recent than the current build > of Windows. Rather than using VerifyVersionInfo for this, shouldn't the check simply compare the SDK version to the targeted CMAKE_SYSTEM_VERSION? If we are cross-compiling or otherwise specifying a specific target version of Windows then we do not want the SDK to exceed that regardless of what the host is running. Also, the sorting logic in GetWindows10SDKVersion appears to use lexicographic string ordering rather than a component-wise integer comparison. This will not always produce the correct result. This is another candidate for using cmSystemTools::VersionCompare. > There is one thing that I've changed that I want to make sure is the > right thing. As it stands, CMAKE_SYSTEM_VERSION is only valid when > cross-compiling, I've changed the CMakeDetermineSystem.cmake file to > not use the HOST_SYSTEM_VERSION when CMAKE_SYSTEM_VERSION is set. > Otherwise, we can only use this feature through CMAKE_SYSTEM_VERSION > on cross-compiling scenarios. That makes sense. I've split that out into its own commit and explained the motivation in the commit message. See attached patch. > I'm not sure what the best way to test this feature, it can be added > to any desktop project on Windows 10 and it should work properly. I've > tried it with CMake itself and it's working fine and building against > the Win10 SDK. We could have the test suite detect when it is building on a Windows 10 host and then add a test that sets CMAKE_WINDOWS_TARGET_PLATFORM_VERSION and verifies that the value ends up in a generated project file. We already have some tests that parse the generated .sln file to check for specific content. Also just simply by running on a Win 10 host then the entire test suite should build with CMAKE_SYSTEM_VERSION set automatically high enough to enable default SDK selection. Please look at setting up nightly testing submissions to the dashboard from such a host once the changes are integrated. 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 informat
Re: [cmake-developers] [Patch] Adding Windows 10 support
On 09/23/2015 06:48 PM, Gilles Khouzam wrote:
> This adds only the WINDOWS_TARGET_PLATFORM_VERSION property as it
> currently only supports the desktop scenario and is extracted
> from the rest of the Windows 10 Store support.
Thanks. While reviewing this much simpler patch I realized that
the WindowsTargetPlatformVersion is more like PlatformToolset than
I previously thought. This led me to another design, perhaps closer
to one of your earlier patches, in which the VS 2015+ generators
select the WindowsTargetPlatformVersion up front based either on
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION or on a computed default.
Either way we should set CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION
to report the selection to CMakeDetermineCompilerId for use in
"CompilerId/VS-10.vcxproj.in". For now I decided to leave out
support for per-target WINDOWS_TARGET_PLATFORM_VERSION properties.
While testing these changes I found a bug that I've now fixed:
cmCoreTryCompile: Fix internal argument vector construction
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=710bde43
Please try out the attached patches based on that version. Then
provide fixup patches based on the comments below if needed.
> If CMAKE_SYSTEM_VERSION is set to 10.0 then
After your change to add a third component to CMAKE_HOST_SYSTEM_VERSION
the value of CMAKE_SYSTEM_VERSION on a Windows 10 host may have
a third component. Therefore we should check that the version
starts with "10.0" rather than is exactly this version. Actually
perhaps we should use cmSystemTools::VersionCompare to do actual
integer version component checks.
> the latest Windows 10 SDK but not more recent than the current
> build of Windows.
Rather than using VerifyVersionInfo for this, shouldn't the check
simply compare the SDK version to the targeted CMAKE_SYSTEM_VERSION?
If we are cross-compiling or otherwise specifying a specific target
version of Windows then we do not want the SDK to exceed that
regardless of what the host is running.
Also, the sorting logic in GetWindows10SDKVersion appears to use
lexicographic string ordering rather than a component-wise integer
comparison. This will not always produce the correct result. This
is another candidate for using cmSystemTools::VersionCompare.
> There is one thing that I've changed that I want to make sure is
> the right thing. As it stands, CMAKE_SYSTEM_VERSION is only valid
> when cross-compiling, I've changed the CMakeDetermineSystem.cmake
> file to not use the HOST_SYSTEM_VERSION when CMAKE_SYSTEM_VERSION
> is set. Otherwise, we can only use this feature through
> CMAKE_SYSTEM_VERSION on cross-compiling scenarios.
That makes sense. I've split that out into its own commit and
explained the motivation in the commit message. See attached
patch.
> I'm not sure what the best way to test this feature, it can be
> added to any desktop project on Windows 10 and it should work
> properly. I've tried it with CMake itself and it's working fine
> and building against the Win10 SDK.
We could have the test suite detect when it is building on a
Windows 10 host and then add a test that sets
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION and verifies that the
value ends up in a generated project file. We already have
some tests that parse the generated .sln file to check for
specific content.
Also just simply by running on a Win 10 host then the entire test
suite should build with CMAKE_SYSTEM_VERSION set automatically high
enough to enable default SDK selection. Please look at setting up
nightly testing submissions to the dashboard from such a host once
the changes are integrated.
Thanks,
-Brad
>From 267153a2ed1417fe16e679d21d34927802e31e2c Mon Sep 17 00:00:00 2001
Message-Id: <267153a2ed1417fe16e679d21d34927802e31e2c.1443126273.git.brad.k...@kitware.com>
From: Gilles Khouzam
Date: Wed, 23 Sep 2015 14:27:07 -0700
Subject: [PATCH 1/3] Allow CMAKE_SYSTEM_VERSION to be set without
CMAKE_SYSTEM_NAME
Teach CMakeDetermineSystem to check for a CMAKE_SYSTEM_VERSION setting
even when CMAKE_SYSTEM_NAME is not set. This will allow builds on the
host OS to target other versions of the OS without full cross-compiling.
---
Modules/CMakeDetermineSystem.cmake | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Modules/CMakeDetermineSystem.cmake b/Modules/CMakeDetermineSystem.cmake
index fa14641..d9f7579 100644
--- a/Modules/CMakeDetermineSystem.cmake
+++ b/Modules/CMakeDetermineSystem.cmake
@@ -123,7 +123,9 @@ elseif(CMAKE_VS_WINCE_VERSION)
set(PRESET_CMAKE_SYSTEM_NAME TRUE)
else()
set(CMAKE_SYSTEM_NAME "${CMAKE_HOST_SYSTEM_NAME}")
- set(CMAKE_SYSTEM_VERSION "${CMAKE_HOST_SYSTEM_VERSION}")
+ if(NOT DEFINED CMAKE_SYSTEM_VERSION)
+set(CMAKE_SYSTEM_VERSION "${CMAKE_HOST_SYSTEM_VERSION}")
+ endif()
set(CMAKE_SYSTEM_PROCESSOR "${CMAKE_HOST_SYSTEM_PROCESSOR}")
set(CMAKE_CROSSCOMPILING FALSE)
set(PRESET_CMAKE_SYSTEM_NAME FALSE)
--
2.5.1
>From b199b0442c06cc80cd5212d89561ee712fef3408 Mon Sep 17 00:00:00 20
Re: [cmake-developers] [Patch] Adding Windows 10 support
Ok, I've got this working as discussed. This adds only the WINDOWS_TARGET_PLATFORM_VERSION property as it currently only supports the desktop scenario and is extracted from the rest of the Windows 10 Store support. This property enables a Windows 10 Desktop project to use a specific version of the Windows 10. If CMAKE_SYSTEM_VERSION is set to 10.0 then the latest Windows 10 SDK but not more recent than the current build of Windows. If you want to specify a specific version to use, then there is the global property CMAKE_WINDOWS_TARGET_PLATFORM_VERSION that will be passed down to each target. To specify a value for a specific target there is the target property WINDOWS_TARGET_PLATFORM_VERSION. There is one thing that I've changed that I want to make sure is the right thing. As it stands, CMAKE_SYSTEM_VERSION is only valid when cross-compiling, I've changed the CMakeDetermineSystem.cmake file to not use the HOST_SYSTEM_VERSION when CMAKE_SYSTEM_VERSION is set. Otherwise, we can only use this feature through CMAKE_SYSTEM_VERSION on cross-compiling scenarios. I'm not sure what the best way to test this feature, it can be added to any desktop project on Windows 10 and it should work properly. I've tried it with CMake itself and it's working fine and building against the Win10 SDK. Yes, you have the right versions for all the CMAKE_HOST_SYSTEM_VERSION for the different OS versions. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Wednesday, September 23, 2015 07:17 To: Gilles Khouzam Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/23/2015 10:03 AM, Gilles Khouzam wrote: > If the property is not present then the default is to use the Windows 8.1 SDK. Thanks for explaining that VS behavior. > I'm suggesting that if the SYSTEM_NAME is Windows but the Version is > set to 10.0 then we can use the same logic as for Store apps. Yes, if CMAKE_SYSTEM_NAME is "Windows" and CMAKE_SYSTEM_VERSION indicates Windows > 8.1 then we should use the latest SDK that is available but not newer than the version of Windows targeted. BTW, what are the values of CMAKE_HOST_SYSTEM_VERSION on Windows 7, 8, 8.1, and 10 when CMake is built with the new manifest file? IIUC they should be: Windows 7 => 6.1 Windows 8 => 6.2 Windows 8.1 => 6.3 Windows 10 => 10.0 plus a third component for the Windows build number. Thanks, -Brad WindowsTargetPlatform.patch Description: WindowsTargetPlatform.patch -- 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
On 09/23/2015 10:03 AM, Gilles Khouzam wrote: > If the property is not present then the default is to use the Windows 8.1 SDK. Thanks for explaining that VS behavior. > I'm suggesting that if the SYSTEM_NAME is Windows but the Version is set > to 10.0 then we can use the same logic as for Store apps. Yes, if CMAKE_SYSTEM_NAME is "Windows" and CMAKE_SYSTEM_VERSION indicates Windows > 8.1 then we should use the latest SDK that is available but not newer than the version of Windows targeted. BTW, what are the values of CMAKE_HOST_SYSTEM_VERSION on Windows 7, 8, 8.1, and 10 when CMake is built with the new manifest file? IIUC they should be: Windows 7 => 6.1 Windows 8 => 6.2 Windows 8.1 => 6.3 Windows 10 => 10.0 plus a third component for the Windows build number. 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
>CMAKE_SYSTEM_NAME is already always defined to a value detected from the host >system when not defined by a toolchain file or by the user in the cache. On a >Windows host the value will be "Windows". >I don't fully understand the case in question. When not building for Windows >Store, does WindowsTargetPlatformVersion need a value if the user does not >request one? What happens if it does not get a value? Is it >needed for >Windows 10 Desktop? Ok, if the CMAKE_SYSTEM_NAME is defined as Windows by default, then this should be good. Yes, the property is also used in desktop if someone wants to use the Windows 10 SDK instead of the Windows 8.1 SDK. If the property is not present then the default is to use the Windows 8.1 SDK. I'm suggesting that if the SYSTEM_NAME is Windows but the Version is set to 10.0 then we can use the same logic as for Store apps. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Wednesday, September 23, 2015 05:38 To: Gilles Khouzam Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/23/2015 01:29 AM, Gilles Khouzam wrote: > Now, for the default behavior, if > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is set through a toolchain file > or the project, then that will be the default which will initialize > the WINDOWS_TARGET_PLATFORM_VERSION for each target through the > SetPropertyDefault initialization call. On the other hand, if > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is not set, nothing should > happen since this is not a required property other than for Windows 10 > Universal (store) apps, the default behavior in that case should be to > not have the property. Okay. > There is one open issue though. How should we have the value for > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION be the latest installed SDK when > this is not a Windows Store project? For Windows Store projects this > would get set if the property is not defined through the > InitializeSystem procedure. How would we handle this for the non > Windows Store case? Do this based on the version and no > CMAKE_SYSTEM_NAME defined? Or should we force there to be a > CMAKE_SYSTEM_NAME to be defined as Windows for example? CMAKE_SYSTEM_NAME is already always defined to a value detected from the host system when not defined by a toolchain file or by the user in the cache. On a Windows host the value will be "Windows". I don't fully understand the case in question. When not building for Windows Store, does WindowsTargetPlatformVersion need a value if the user does not request one? What happens if it does not get a value? Is it needed for Windows 10 Desktop? 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
On 09/23/2015 01:29 AM, Gilles Khouzam wrote: > Now, for the default behavior, if > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is set through a toolchain > file or the project, then that will be the default which will > initialize the WINDOWS_TARGET_PLATFORM_VERSION for each target > through the SetPropertyDefault initialization call. On the other > hand, if CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is not set, > nothing should happen since this is not a required property other > than for Windows 10 Universal (store) apps, the default behavior > in that case should be to not have the property. Okay. > There is one open issue though. How should we have the value for > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION be the latest installed SDK > when this is not a Windows Store project? For Windows Store > projects this would get set if the property is not defined > through the InitializeSystem procedure. How would we handle this > for the non Windows Store case? Do this based on the version and > no CMAKE_SYSTEM_NAME defined? Or should we force there to be a > CMAKE_SYSTEM_NAME to be defined as Windows for example? CMAKE_SYSTEM_NAME is already always defined to a value detected from the host system when not defined by a toolchain file or by the user in the cache. On a Windows host the value will be "Windows". I don't fully understand the case in question. When not building for Windows Store, does WindowsTargetPlatformVersion need a value if the user does not request one? What happens if it does not get a value? Is it needed for Windows 10 Desktop? 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
Thanks for the feedback Brad,
I have rebased the changes and I think that I have the proper default
functionality properly implemented. I've extracted the
WINDOWS_TARGET_PLATFORM_VERSION changes into a separate patch.
WINDOWS_TARGET_PLATFORM_VERSION is a target property, for that will specify the
WindowsTargetPlatformVersion tag in VS.
WINDOWS_TARGET_PLATFORM_MIN_VERSION is a target property that will specify the
WindowsTargetPlatformMinVersion tag in VS.
Now, for the default behavior, if CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is set
through a toolchain file or the project, then that will be the default which
will initialize the WINDOWS_TARGET_PLATFORM_VERSION for each target through the
SetPropertyDefault initialization call. On the other hand, if
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is not set, nothing should happen since
this is not a required property other than for Windows 10 Universal (store)
apps, the default behavior in that case should be to not have the property.
There is one open issue though. How should we have the value for
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION be the latest installed SDK when this is
not a Windows Store project? For Windows Store projects this would get set if
the property is not defined through the InitializeSystem procedure. How would
we handle this for the non Windows Store case? Do this based on the version and
no CMAKE_SYSTEM_NAME defined? Or should we force there to be a
CMAKE_SYSTEM_NAME to be defined as Windows for example?
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Monday, September 21, 2015 08:09
To: Gilles Khouzam
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support
On 09/10/2015 09:31 PM, Gilles Khouzam wrote:
> Here is the patch for Windows 10 Support which would be issue 15686.
[snip]
> This change requires the change for issue 0015674 for determining the
> version of the OS.
That change is now done as posted here:
[PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14327/focus=14478
Please rebase the rest of your Win 10 patch on that and revise according to the
comments below.
> New Properties Added:
> VS_TARGET_PLATFORM_VERSION: Target property. Specifies that the SDK
> being used to compile the project. For Windows 10 RTM, that will be
> 10.0.10240.0.
> For Store apps, this property is required by Visual Studio. If the
> property is not specified, the system will be queried for the
> available Windows 10 SDKs installed and the most recent but less than
> or equal version than the host system version will be set as a default
> (in
> CMAKE_VS_TARGET_PLATFORM_VERSION) and used.
Please split this part out into its own (preceding) patch, much like was done
for the windows version detection. Also, currently the patch does not
implement [CMAKE_]VS_TARGET_PLATFORM_VERSION as previously discussed:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14201/focus=14246
For example:
> + if (this->SystemVersion == "10.0")
> +{
> +// Find the default version of the Windows 10 SDK and set
> +// a default CMAKE_VS_TARGET_PLATFORM_VERSION
> +std::string sdkVersion = GetWindows10SDKVersion();
> +if(sdkVersion.empty())
> + {
> + e << "Could not find an appropriate version of the Windows 10 SDK"
> +<< "installed on this machine";
> + mf->IssueMessage(cmake::FATAL_ERROR, e.str());
> + return false;
> + }
> +mf->AddDefinition("CMAKE_VS_TARGET_PLATFORM_VERSION",
> + sdkVersion.c_str());
> +}
Logic like this should be used to select a default SDK when neither the
property nor the variable is set. I think we've had some confusion between the
user-settable target property/variable and the generator- reported selection
result used by the compiler id. The latter is used here in your patch:
> +set(id_WindowsTargetPlatformVersion
> + "${CMAKE_VS_TARGET_PLATFORM_VERSION} + WindowsTargetPlatformVersion>")
Currently the CMAKE_VS_ convention is used by the VS generators to report
information about what the've decided. I think this makes sense so a variable
called CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION
could serve this purpose (reporting to project code what VS decided to use).
What we need separately is an interface for users and/or project code to select
a specific WindowsTargetPlatformVersion. The target property currently called
VS_TARGET_PLATFORM_VERSION will work well for project code to set the value for
specific targets. We still need another setting for users or toolchain files
to set to make it a project-wide default. Perhaps we should have a separate
variable called
CMAKE_WINDOWS
Re: [cmake-developers] [Patch] Adding Windows 10 support
On 09/10/2015 09:31 PM, Gilles Khouzam wrote:
> Here is the patch for Windows 10 Support which would be issue 15686.
[snip]
> This change requires the change for issue 0015674 for determining the
> version of the OS.
That change is now done as posted here:
[PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14327/focus=14478
Please rebase the rest of your Win 10 patch on that and revise according
to the comments below.
> New Properties Added:
> VS_TARGET_PLATFORM_VERSION: Target property. Specifies that the SDK being
> used to compile the project. For Windows 10 RTM, that will be 10.0.10240.0.
> For Store apps, this property is required by Visual Studio. If the property
> is not specified, the system will be queried for the available Windows 10
> SDKs installed and the most recent but less than or equal version than the
> host system version will be set as a default (in
> CMAKE_VS_TARGET_PLATFORM_VERSION) and used.
Please split this part out into its own (preceding) patch, much like was
done for the windows version detection. Also, currently the patch does
not implement [CMAKE_]VS_TARGET_PLATFORM_VERSION as previously discussed:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14201/focus=14246
For example:
> + if (this->SystemVersion == "10.0")
> +{
> +// Find the default version of the Windows 10 SDK and set
> +// a default CMAKE_VS_TARGET_PLATFORM_VERSION
> +std::string sdkVersion = GetWindows10SDKVersion();
> +if(sdkVersion.empty())
> + {
> + e << "Could not find an appropriate version of the Windows 10 SDK"
> +<< "installed on this machine";
> + mf->IssueMessage(cmake::FATAL_ERROR, e.str());
> + return false;
> + }
> +mf->AddDefinition("CMAKE_VS_TARGET_PLATFORM_VERSION",
> + sdkVersion.c_str());
> +}
Logic like this should be used to select a default SDK when neither the
property nor the variable is set. I think we've had some confusion
between the user-settable target property/variable and the generator-
reported selection result used by the compiler id. The latter is
used here in your patch:
> +set(id_WindowsTargetPlatformVersion
> "${CMAKE_VS_TARGET_PLATFORM_VERSION}")
Currently the CMAKE_VS_ convention is used by the VS generators
to report information about what the've decided. I think this makes
sense so a variable called CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION
could serve this purpose (reporting to project code what VS decided
to use).
What we need separately is an interface for users and/or project code
to select a specific WindowsTargetPlatformVersion. The target property
currently called VS_TARGET_PLATFORM_VERSION will work well for project
code to set the value for specific targets. We still need another
setting for users or toolchain files to set to make it a project-wide
default. Perhaps we should have a separate variable called
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION
and rename the target property to just
WINDOWS_TARGET_PLATFORM_VERSION
The property should be initialized via SetPropertyDefault to copy
the variable setting into each target.
-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
Re: [cmake-developers] [Patch] Adding Windows 10 support
Here is the patch for Windows 10 Support which would be issue 15686. This is dependent on the patch for issue 15674 which is the version detection change. >From the commit message: This change adds support for Windows 10 Universal Applications. A Windows 10 Universal Application can be targeted by setting: CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION=10.0 There are no WindowsPhone apps, universal apps target both phone and store. New Properties Added: VS_TARGET_PLATFORM_VERSION: Target property. Specifies that the SDK being used to compile the project. For Windows 10 RTM, that will be 10.0.10240.0. For Store apps, this property is required by Visual Studio. If the property is not specified, the system will be queried for the available Windows 10 SDKs installed and the most recent but less than or equal version than the host system version will be set as a default (in CMAKE_VS_TARGET_PLATFORM_VERSION) and used. VS_TARGET_PLATFORM_MIN_VERSION: Target Property. Specifies the minimum version of the OS that the project can target. VS_DESKTOP_EXTENSIONS_VERSION, VS_MOBILE_EXTENSIONS_VERSIONS, VS_IOT_EXTENSIONS_VERSION: Target property. When specifying these properties a reference to the version of the SDK specified will be added to the project allowing to target the extended functionality in a universal project. VS_IOT_STARTUP_TASK: Target property. Specifies that the target should be built as an IOT continuous background task. VS_TOOL_OVERRIDE: Source property. For common files, allows to modify the tool that gets applied to the source file. For example, when adding a .RESW file to the project, since CMake doesn't know how to handle them, it will assign a None Tool to the file. This allows to override the default and specify a new tool to handle. This change requires the change for issue 0015674 for determining the version of the OS. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Thursday, September 10, 2015 12:08 To: Gilles Khouzam Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/10/2015 03:04 PM, Brad King wrote: > On 09/10/2015 02:37 PM, Gilles Khouzam wrote: >> I can split it up in multiple patches if that makes it easier. > > Yes, please. That makes review and future reading of history easier > because we see a commit message associated with each corresponding set > of changes. > > Please order the patches so that no existing functionality breaks at > any step and everything compiles. Also please produce the patches with "git format-patch" so that commit messages and authorship info comes with each one. Thanks, -Brad Issue15686.patch Description: Issue15686.patch -- 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
On 09/10/2015 03:04 PM, Brad King wrote: > On 09/10/2015 02:37 PM, Gilles Khouzam wrote: >> I can split it up in multiple patches if that makes it easier. > > Yes, please. That makes review and future reading of history easier > because we see a commit message associated with each corresponding > set of changes. > > Please order the patches so that no existing functionality breaks at > any step and everything compiles. Also please produce the patches with "git format-patch" so that commit messages and authorship info comes with each one. 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
On 09/10/2015 02:37 PM, Gilles Khouzam wrote: > I don't know that deprecating the API and making it require a > manifest was a better solution, but it does require more > intentional work on the developer before just using the API. The API should not be deprecated if there is any use case for which no replacement is available. The manifest approach does raise the bar, but it also makes no sense for library code that wants to know the Windows version, and still requires use of a deprecated API. MS should have just provided the version helper APIs and updated the GetVersionEx docs to refer to them as preferred. > Added support for manifest files...(VisualStudio 10 generator only) We need it to be supported on all generators. Otherwise when one builds CMake with another generator (like our release binaries) it will not be able to detect the proper version of Windows. The Makefile and Ninja generators already have some support for running the manifest tool while linking a binary. How might one detect Windows 10 in a .cmd (.bat) script? Perhaps we can query something externally instead of using GetVersionEx. Of course having custom manifest support will be nice for apps anyway. > I can split it up in multiple patches if that makes it easier. Yes, please. That makes review and future reading of history easier because we see a commit message associated with each corresponding set of changes. Please order the patches so that no existing functionality breaks at any step and everything compiles. 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
Brad, >From my understanding GetVersionEx was causing a nightmare of app >compatibility issues where developers would make the wrong comparison or >assumption based on the version and applications would break on new releases. >I don't know that deprecating the API and making it require a manifest was a >better solution, but it does require more intentional work on the developer >before just using the API. For the usage that CMake is using it is benign and >doesn't look like it would cause compatibility issues. Here's the updated patch for Windows 10 support. 1. Added support for Windows Universal applications as CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION=10.0 2. Added support for manifest files, when specifying a manifest as a source file, it will be added to the tag of the section in the vcxproj file (VisualStudio 10 generator only). Multiple manifests could be added. 3. Added a manifest to the CMake executables to enable proper version API support on Windows 8 and above. The file is Source\cmake.version.manifest. 4. Added a detection mechanism to figure out which Windows 10 SDK is installed and can be used on the machine. This follows the detection logic that VS 2015 uses. The SDK selected will be the latest SDK that is less or equal to the build of the HOST. This change requires the manifest. 5. Added Windows 10 Universal tests in VSWinStorePhone 6. Added a 2 new target properties: VS_TARGET_PLATFORM_VERSION and VS_TARGET_PLATFORM_MIN_VERSION, these set the and tags in the vcxproj file. If VS_TARGET_PLATFORM_VERSION is not set for a target and is required, a default is set a CMAKE_VS_TARGET_PLATFORM_VERSION based on the lastest usable Windows 10 SDK. 7. Added a new target property VS_TOOL_OVERRIDE to enable adding new file types to VS without requiring to teach CMake how to handle them. This property, set on a source file will override the default tool assigned in Visual Studio. This enables support for RESW files for example without teaching CMake how to handle them. 8. Added support for Windows 10 extensions with 3 new properties: VS_DESKTOP_EXTENSIONS_VERSION, VS_MOBILE_EXTENSIONS_VERSION and VS_IOT_EXTENSIONS_VERSION. These specify the version of the different extensions and whether they are used. When an extension is used, an SDK reference is added for that extension. 9. Added a new property: VS_IOT_STARTUP_TASK to specify if the target has a startup task for and IOT project. I realize that there are a lot of changes in here, but the combination of them are all required for proper Windows 10 support. I can split it up in multiple patches if that makes it easier. #2 and #3 could be a different patch that Windows 10 support depends on. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Thursday, September 10, 2015 06:39 To: Gilles Khouzam Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/09/2015 05:48 PM, Gilles Khouzam wrote: > Even though GetVersionEx is deprecated, it is the right way to get the > system version, loading ntdll and getting RtlGetVersion is not a good > practice as those are private APIs that could change. The change was contributed recently: Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8.1 (#15674) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d4736d53 for this issue: http://www.cmake.org/Bug/view.php?id=15674 I've re-opened the issue. I would really like to know why MS deprecated GetVersionEx. The Version Helper APIs are only good for checking >= level, not getting the actual version. Why not add the helpers and leave GetVersionEx available too? Why do we need to add a manifest just to get the OS version? What is a library author supposed to do when s/he cannot control the application that will link the library? FYI, the GetVersionEx documentation page: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx has a community-mentioned recommendation to use RtlGetVersion. Thanks, -Brad Windows10.patch Description: Windows10.patch -- 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
On 09/09/2015 05:48 PM, Gilles Khouzam wrote: > Even though GetVersionEx is deprecated, > it is the right way to get the system version, loading ntdll and > getting RtlGetVersion is not a good practice as those are private > APIs that could change. The change was contributed recently: Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8.1 (#15674) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d4736d53 for this issue: http://www.cmake.org/Bug/view.php?id=15674 I've re-opened the issue. I would really like to know why MS deprecated GetVersionEx. The Version Helper APIs are only good for checking >= level, not getting the actual version. Why not add the helpers and leave GetVersionEx available too? Why do we need to add a manifest just to get the OS version? What is a library author supposed to do when s/he cannot control the application that will link the library? FYI, the GetVersionEx documentation page: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx has a community-mentioned recommendation to use RtlGetVersion. 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
Thanks Brad. As I've been writing this code, I was looking for the build number and came across the code in cmGlobalGenerator that sets the CMAKE_HOST_SYSTEM_VERSION. Even though GetVersionEx is deprecated, it is the right way to get the system version, loading ntdll and getting RtlGetVersion is not a good practice as those are private APIs that could change. On newer systems (Windows 8 and above) by default the version returned doesn't go beyond Windows 8 Build 9200, but you can apply a manifest to the executable that will let the API give you the correct information and this is a more correct way of handling this. I don't know if there's another reason for the code to be as it is, but I think it would be a better practice to opt into the proper GetVersionEx behavior by adding a manifest than by calling GetProcAddress on an internal API. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Wednesday, September 9, 2015 08:00 To: Gilles Khouzam Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/03/2015 03:19 PM, Gilles Khouzam wrote: > 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. Yes, I think that makes sense. 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
On 09/03/2015 03:19 PM, Gilles Khouzam wrote: > 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. Yes, I think that makes sense. 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
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.k...@kitware.com] Sent: Wednesday, September 2, 2015 08:25 To: Gilles Khouzam Cc: cmake-developers@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 and , 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 -- 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
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 and , 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 -- 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
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:brad.k...@kitware.com] Sent: Monday, August 31, 2015 13:06 To: Gilles Khouzam Cc: cmake-developers@cmake.org 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
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
[cmake-developers] [Patch] Adding Windows 10 support
This patch adds support for Windows 10 Universal application in CMake. Starting with Windows 10, Universal applications are the new equivalent to Windows Store and Windows Phone apps. The patch adds similar support that we had for Windows 8.0 and Windows 8.1 for Store apps. This does not add WindowsPhone 10 support as it is included in WindowsStore 10 support. To target a Windows Universal App, CMAKE_SYSTEM_VERSION should be set to WindowsStore and CMAKE_SYSTEM_VERSION should be set to 10.0 _ As part of this, some new properties have been added: Ability to set Desktop, Mobile and IOT (Internet of Things) extensions using the following properties /prop_tgt/VS_DESKTOP_EXTENSIONS_VERSION /prop_tgt/VS_IOT_EXTENSIONS_VERSION /prop_tgt/VS_MOBILE_EXTENSIONS_VERSION For each of these properties, if it is set, a reference to the extension SDK will be added allowing the application to target functionality specific to Desktop, Mobile or IOT respectively. For the time being the version of the SDK is 10.0.10240.0 for each of those but will change as new versions of the Windows 10 SDK come one. Set the project to be a IOT continuous running task. /prop_tgt/VS_IOT_STARTUP_TASK Specify the target platform version and minimum version /prop_tgt/VS_TARGET_PLATFORM_MIN_VERSION /prop_tgt/VS_TARGET_PLATFORM_VERSION By specifying either of these properties, the respective visual studio property WindowsTargetPlatformVersion and WindowsTargetPlatformMinVersion will be set to the value set. If the value is not set, the latest SDK version will be used and queried in the same way that VCVars.bat from VS 2015 figures out which SDKs are installed; since this property is required for Universal apps, the detection code will add a definition VS_DEFAULT_TARGET_PLATFORM_VERSION on the makefile for proper compiler detection. Adding a new file property: VS_TOOL_OVERRIDE to override the default tool that a file will be processed with. By default the extension is used to specify a tool, this property will allow to change the default or set a new tool that CMake might not know about. For example this allows to process .RESW multi language files without having to specifically add support to CMake. This change should address the following issues: http://www.cmake.org/Bug/view.php?id=15670 [CMake 0015670]: Add support for setting "Windows target platform version" in VS2015 https://public.kitware.com/Bug/view.php?id=15686 [CMake 0015686]: Windows phone projects targeting Windows 10 differ from Windows Phone 8.1 projects https://public.kitware.com/Bug/view.php?id=15662 [CMake 0015662]: Add support for Windows/Windows Phone SDKs with Visual Studio 2015 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 installed, where we would look for the desktop toolset being installed based on the CMAKE_SYSTEM_VERSION instead of by using the Generator requested. The change is simply to make the desktop detection code be virtual. As long as there is a desktop toolset for the current generator, things would work properly. We've also added Windows 10 support to our dashboard to keep these feature tested. Thanks ~Gilles Windows10Universal.patch Description: Windows10Universal.patch -- 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
