(0040282)
Brad King (manager)
2016-01-21 08:33

For reference, this was also reported here:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/54435/focus=54440 [^]

(0040283)
Brad King (manager)
2016-01-21 08:37

This must have been caused by the changes for 0015831.

In "C:\Program Files (x86)\Windows Kits\10\include" what SDK directories do you have? Which ones contain "um\windows.h"?

(0040284)
Brad King (manager)
2016-01-21 09:03

For reference, the logic changed between 3.4.1 and 3.4.2 where we select the Windows 10 SDK:

https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalVisualStudio14Generator.cxx;hb=v3.4.2#l242 [^]

The old logic could fail to choose any SDK in some circumstances, but the new logic should always choose one if any exists so it is very strange that this fails. I wonder if somehow the filter that requires um\windows.h to exist is somehow filtering out everything, hence the question in 0015929:0040283.

(0040285)
Bruce Pascoe (reporter)
2016-01-21 10:39

@Brad: C:\Program Files (x86)\Windows Kits\10\Include contains:

* 10.0.10150.0
* 10.0.10240.0

Neither one contains "um/windows.h" or even a windows.h anywhere. My next strategy was to drop to the command line, since I know I can compile Win32 applications on this machine, and this was the result:

C:\>dir /s /b /a windows.h
C:\cygwin64\usr\i686-pc-cygwin\sys-root\usr\include\w32api\windows.h
C:\cygwin64\usr\i686-pc-mingw32\sys-root\mingw\include\windows.h
C:\cygwin64\usr\i686-w64-mingw32\sys-root\mingw\include\windows.h
C:\cygwin64\usr\include\w32api\windows.h
C:\cygwin64\usr\x86_64-w64-mingw32\sys-root\mingw\include\windows.h
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include\Windows.h
C:\Program Files (x86)\Windows Kits\8.1\Include\um\Windows.h

Looking at the allegro_monolith.vcxproj generated by CMake 3.4.1 (which I can compile successfully), CMake appears to have chosen the 8.1 SDK. I guess that's all MSVC 2015 installs?

(0040287)
Brad King (manager)
2016-01-21 11:05

Re 0015929:0040285: Thanks. It looks like there actually is no Windows 10 SDK installed in your case. Since the machine runs Windows 10 CMake 3.4 tries to build for the host by default and wants to find a Windows 10 SDK.

Summary:

* CMake 3.3 and below "work" because they don't know about Windows 10 or its SDKs and so build for Windows 8.

* CMake 3.4.0 and 3.4.1 know about Windows 10 and its SDKs but incorrectly choose incomplete SDKs because the directories that would contain them happen to exist for other reasons. This happened to work in some cases, appeared to work in others, and failed in yet more cases (hence the fix for 3.4.2).

* CMake 3.4.2 knows about Windows 10, will only select a Windows 10 SDK that is actually installed, and therefore fails on Windows 10 when no SDK is available.

* This all affects only the Visual Studio 14 2015 generator because it is the only one that tries to find a Windows 10 SDK or build for Windows 10 because earlier VS versions pre-date Windows 10.

(0040288)
Brad King (manager)
2016-01-21 11:08

Re 0015929:0040285, 0015929:0040287: CMake does not make any attempt to explicitly find a Windows SDK for versions earlier than Windows 10 and just uses whatever the VS IDE selects. This changed for VS 2015 and Windows 10 because VS now makes the SDK something that can be selected, and this is needed in order to target Windows 10 natively.

(0040289)
Bruce Pascoe (reporter)
2016-01-21 11:09

Problem is that Visual Studio 2015 itself apparently doesn't include a Windows 10 SDK, only the 8.1 SDK. So this will cause a lot of confusion.

(0040290)
Brad King (manager)
2016-01-21 11:12

Gilles, please comment here since you developed the Windows 10 support. This all appears to have been developed with the assumption that VS 2015 will always have at least one Windows 10 SDK available. 0015929:0040289 points out that this is not true. IIRC the installer makes it optional.

(0040291)
Bruce Pascoe (reporter)
2016-01-21 11:13

In regards to CMake not letting the IDE select the SDK, this behavior has caused issues for me as well: Whenever I switch a project to the "Windows XP" toolset I have to go in and delete the CMake-selected SDK from the include paths otherwise the project won't compile. But that should probably have a separate bug opened for it, if at all.

(0040292)
Brad King (manager)
2016-01-21 11:24

Re 0015929:0040291: Yes, please open a separate issue for that or come to the dev list at https://cmake.org/mailman/listinfo/cmake-developers [^] to discuss it.

(0040294)
Brad King (manager)
2016-01-21 12:52

Here is a fix to simply not reject the lack of a Windows 10 SDK:

VS: Do not fail on Windows 10 with VS 2015 if no SDK is available
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d7e863c1 [^]

(0040295)
Gilles Khouzam (developer)
2016-01-21 13:48

If the Windows 10 SDK is not installed, the default 8.1 SDK should be used. Let me install a clean machine and look at the current vs expected behavior.

(0040306)
Brad King (manager)
2016-01-22 09:51

Bruce, the change linked in 0015929:0040294 should now be available in a nightly binary:

https://cmake.org/files/dev/?C=M;O=D [^]

as of version 3.4.20160121-gd194d or later. Please try it out to verify the fix.

The "cmake-3.4.20160121-gd194d-win32-x86.zip" file can be extracted anywhere and run directly independent of the installed 3.4.2 version. The "cmake-3.4.20160121-gd194d-win32-x86.msi" file is an installer (due to the upcoming transition from the .exe installer to the .msi installer you'll need to manually uninstall CMake 3.4.2 first to use it).

(0040307)
Gilles Khouzam (developer)
2016-01-22 16:51

Thanks Brad,

The change makes sense, the one caveat that I would like to raise, is that now, if someone specifically asks for a Windows 10 SDK, if none are present then the 8.1 one will still be used. I don't know that with the current model, this can be solved, but I wanted to at least raise the issue.

(0040308)
Bruce Pascoe (reporter)
2016-01-23 01:01

That nightly fixed the issue, thanks!

Also, +1 for the polishing apparently done to cmake-gui. It doesn't feel "cheap" anymore. :)

(0040315)
Brad King (manager)
2016-01-25 08:49

Re 0015929:0040307: Yes, it's too bad we cannot simultaneously work by default and also diagnose a missing Windows 10 SDK. I did leave the diagnostic in for Windows Store. Also project code that wants to enforce use of the proper SDK version can check CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION itself.

(0040316)
Brad King (manager)
2016-01-25 08:50

Re 0015929:0040308: Great, thanks for testing!

(0040332)
Brad King (manager)
2016-01-27 09:50

This change has been merged back to 'release' and included in the 3.4.3 release.

(0041274)
Kitware Robot (administrator)
2016-06-10 14:21

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Notes
(0040282) Brad King (manager) 2016-01-21 08:33	For reference, this was also reported here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/54435/focus=54440 [^]

(0040283) Brad King (manager) 2016-01-21 08:37	This must have been caused by the changes for 0015831. In "C:\Program Files (x86)\Windows Kits\10\include" what SDK directories do you have? Which ones contain "um\windows.h"?

(0040284) Brad King (manager) 2016-01-21 09:03	For reference, the logic changed between 3.4.1 and 3.4.2 where we select the Windows 10 SDK: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalVisualStudio14Generator.cxx;hb=v3.4.2#l242 [^] The old logic could fail to choose any SDK in some circumstances, but the new logic should always choose one if any exists so it is very strange that this fails. I wonder if somehow the filter that requires um\windows.h to exist is somehow filtering out everything, hence the question in 0015929:0040283.

(0040285) Bruce Pascoe (reporter) 2016-01-21 10:39	@Brad: C:\Program Files (x86)\Windows Kits\10\Include contains: * 10.0.10150.0 * 10.0.10240.0 Neither one contains "um/windows.h" or even a windows.h anywhere. My next strategy was to drop to the command line, since I know I can compile Win32 applications on this machine, and this was the result: C:\>dir /s /b /a windows.h C:\cygwin64\usr\i686-pc-cygwin\sys-root\usr\include\w32api\windows.h C:\cygwin64\usr\i686-pc-mingw32\sys-root\mingw\include\windows.h C:\cygwin64\usr\i686-w64-mingw32\sys-root\mingw\include\windows.h C:\cygwin64\usr\include\w32api\windows.h C:\cygwin64\usr\x86_64-w64-mingw32\sys-root\mingw\include\windows.h C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include\Windows.h C:\Program Files (x86)\Windows Kits\8.1\Include\um\Windows.h Looking at the allegro_monolith.vcxproj generated by CMake 3.4.1 (which I can compile successfully), CMake appears to have chosen the 8.1 SDK. I guess that's all MSVC 2015 installs?

(0040287) Brad King (manager) 2016-01-21 11:05	Re 0015929:0040285: Thanks. It looks like there actually is no Windows 10 SDK installed in your case. Since the machine runs Windows 10 CMake 3.4 tries to build for the host by default and wants to find a Windows 10 SDK. Summary: * CMake 3.3 and below "work" because they don't know about Windows 10 or its SDKs and so build for Windows 8. * CMake 3.4.0 and 3.4.1 know about Windows 10 and its SDKs but incorrectly choose incomplete SDKs because the directories that would contain them happen to exist for other reasons. This happened to work in some cases, appeared to work in others, and failed in yet more cases (hence the fix for 3.4.2). * CMake 3.4.2 knows about Windows 10, will only select a Windows 10 SDK that is actually installed, and therefore fails on Windows 10 when no SDK is available. * This all affects only the Visual Studio 14 2015 generator because it is the only one that tries to find a Windows 10 SDK or build for Windows 10 because earlier VS versions pre-date Windows 10.

(0040288) Brad King (manager) 2016-01-21 11:08	Re 0015929:0040285, 0015929:0040287: CMake does not make any attempt to explicitly find a Windows SDK for versions earlier than Windows 10 and just uses whatever the VS IDE selects. This changed for VS 2015 and Windows 10 because VS now makes the SDK something that can be selected, and this is needed in order to target Windows 10 natively.

(0040289) Bruce Pascoe (reporter) 2016-01-21 11:09	Problem is that Visual Studio 2015 itself apparently doesn't include a Windows 10 SDK, only the 8.1 SDK. So this will cause a lot of confusion.

(0040290) Brad King (manager) 2016-01-21 11:12	Gilles, please comment here since you developed the Windows 10 support. This all appears to have been developed with the assumption that VS 2015 will always have at least one Windows 10 SDK available. 0015929:0040289 points out that this is not true. IIRC the installer makes it optional.

(0040291) Bruce Pascoe (reporter) 2016-01-21 11:13	In regards to CMake not letting the IDE select the SDK, this behavior has caused issues for me as well: Whenever I switch a project to the "Windows XP" toolset I have to go in and delete the CMake-selected SDK from the include paths otherwise the project won't compile. But that should probably have a separate bug opened for it, if at all.

(0040292) Brad King (manager) 2016-01-21 11:24	Re 0015929:0040291: Yes, please open a separate issue for that or come to the dev list at https://cmake.org/mailman/listinfo/cmake-developers [^] to discuss it.

(0040294) Brad King (manager) 2016-01-21 12:52	Here is a fix to simply not reject the lack of a Windows 10 SDK: VS: Do not fail on Windows 10 with VS 2015 if no SDK is available https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d7e863c1 [^]

(0040295) Gilles Khouzam (developer) 2016-01-21 13:48	If the Windows 10 SDK is not installed, the default 8.1 SDK should be used. Let me install a clean machine and look at the current vs expected behavior.

(0040306) Brad King (manager) 2016-01-22 09:51	Bruce, the change linked in 0015929:0040294 should now be available in a nightly binary: https://cmake.org/files/dev/?C=M;O=D [^] as of version 3.4.20160121-gd194d or later. Please try it out to verify the fix. The "cmake-3.4.20160121-gd194d-win32-x86.zip" file can be extracted anywhere and run directly independent of the installed 3.4.2 version. The "cmake-3.4.20160121-gd194d-win32-x86.msi" file is an installer (due to the upcoming transition from the .exe installer to the .msi installer you'll need to manually uninstall CMake 3.4.2 first to use it).

(0040307) Gilles Khouzam (developer) 2016-01-22 16:51	Thanks Brad, The change makes sense, the one caveat that I would like to raise, is that now, if someone specifically asks for a Windows 10 SDK, if none are present then the 8.1 one will still be used. I don't know that with the current model, this can be solved, but I wanted to at least raise the issue.

(0040308) Bruce Pascoe (reporter) 2016-01-23 01:01	That nightly fixed the issue, thanks! Also, +1 for the polishing apparently done to cmake-gui. It doesn't feel "cheap" anymore. :)

(0040315) Brad King (manager) 2016-01-25 08:49	Re 0015929:0040307: Yes, it's too bad we cannot simultaneously work by default and also diagnose a missing Windows 10 SDK. I did leave the diagnostic in for Windows Store. Also project code that wants to enforce use of the proper SDK version can check CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION itself.

(0040316) Brad King (manager) 2016-01-25 08:50	Re 0015929:0040308: Great, thanks for testing!

(0040332) Brad King (manager) 2016-01-27 09:50	This change has been merged back to 'release' and included in the 3.4.3 release.

(0041274) Kitware Robot (administrator) 2016-06-10 14:21	This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2016-01-20 21:25	Bruce Pascoe	New Issue
2016-01-20 21:25	Bruce Pascoe	File Added: CMakeOutput.log
2016-01-21 08:32	Brad King	Relationship added	related to 0015831
2016-01-21 08:33	Brad King	Note Added: 0040282
2016-01-21 08:37	Brad King	Note Added: 0040283
2016-01-21 09:03	Brad King	Note Added: 0040284
2016-01-21 10:39	Bruce Pascoe	Note Added: 0040285
2016-01-21 11:05	Brad King	Note Added: 0040287
2016-01-21 11:08	Brad King	Note Added: 0040288
2016-01-21 11:09	Bruce Pascoe	Note Added: 0040289
2016-01-21 11:12	Brad King	Note Added: 0040290
2016-01-21 11:13	Bruce Pascoe	Note Added: 0040291
2016-01-21 11:24	Brad King	Note Added: 0040292
2016-01-21 11:51	Brad King	Relationship added	related to 0015930
2016-01-21 12:52	Brad King	Note Added: 0040294
2016-01-21 13:48	Gilles Khouzam	Note Added: 0040295
2016-01-22 09:51	Brad King	Note Added: 0040306
2016-01-22 16:51	Gilles Khouzam	Note Added: 0040307
2016-01-23 01:01	Bruce Pascoe	Note Added: 0040308
2016-01-25 08:49	Brad King	Note Added: 0040315
2016-01-25 08:50	Brad King	Note Added: 0040316
2016-01-25 08:50	Brad King	Assigned To	=> Brad King
2016-01-25 08:50	Brad King	Status	new => resolved
2016-01-25 08:50	Brad King	Resolution	open => fixed
2016-01-25 08:50	Brad King	Fixed in Version	=> CMake 3.5
2016-01-25 08:50	Brad King	Target Version	=> CMake 3.5
2016-01-27 09:50	Brad King	Note Added: 0040332
2016-01-27 09:50	Brad King	Fixed in Version	CMake 3.5 => CMake 3.4.3
2016-01-27 09:50	Brad King	Target Version	CMake 3.5 => CMake 3.4.3
2016-06-10 14:21	Kitware Robot	Note Added: 0041274
2016-06-10 14:21	Kitware Robot	Status	resolved => closed