MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015929CMakeCMakepublic2016-01-20 21:252016-06-10 14:21
ReporterBruce Pascoe 
Assigned ToBrad King 
PrioritynormalSeverityblockReproducibilityalways
StatusclosedResolutionfixed 
PlatformWindowsOSWindows 10OS Version1511
Product VersionCMake 3.4.2 
Target VersionCMake 3.4.3Fixed in VersionCMake 3.4.3 
Summary0015929: "Could not find an appropriate version of the Windows 10 SDK"
DescriptionI just upgraded to CMake 3.4.2, and started getting the above message when attempting to build Allegro 5.1. I was using CMake 3.4.1 previously, and that worked just fine. No other changes have been made to my system other than to update CMake.
Steps To Reproduce* Try to build a CMake project.
* Get error "Could not find an appropriate version of the Windows 10 SDK installed on this machine"
* Build fails.
Additional Information* Windows 10 Pro 1511 (10.0.10586) x64
* Visual Studio Community 2015 Update 1
* CMakeOutput.log is attached.
TagsNo tags attached.
Relationships
related to 0015831closed Brad King CMake Version 3.4 with VS 2015 fails to detect a Windows 10 SDK 
related to 0015930closed Kitware Robot MSVC project switched to Windows XP toolset won't compile 
Attached Fileslog CMakeOutput.log (45) 2016-01-20 21:25
https://public.kitware.com/Bug/file/5616/CMakeOutput.log
Issue History
Date ModifiedUsernameFieldChange
2016-01-20 21:25Bruce PascoeNew Issue
2016-01-20 21:25Bruce PascoeFile Added: CMakeOutput.log
2016-01-21 08:32Brad KingRelationship addedrelated to 0015831
2016-01-21 08:33Brad KingNote Added: 0040282
2016-01-21 08:37Brad KingNote Added: 0040283
2016-01-21 09:03Brad KingNote Added: 0040284
2016-01-21 10:39Bruce PascoeNote Added: 0040285
2016-01-21 11:05Brad KingNote Added: 0040287
2016-01-21 11:08Brad KingNote Added: 0040288
2016-01-21 11:09Bruce PascoeNote Added: 0040289
2016-01-21 11:12Brad KingNote Added: 0040290
2016-01-21 11:13Bruce PascoeNote Added: 0040291
2016-01-21 11:24Brad KingNote Added: 0040292
2016-01-21 11:51Brad KingRelationship addedrelated to 0015930
2016-01-21 12:52Brad KingNote Added: 0040294
2016-01-21 13:48Gilles KhouzamNote Added: 0040295
2016-01-22 09:51Brad KingNote Added: 0040306
2016-01-22 16:51Gilles KhouzamNote Added: 0040307
2016-01-23 01:01Bruce PascoeNote Added: 0040308
2016-01-25 08:49Brad KingNote Added: 0040315
2016-01-25 08:50Brad KingNote Added: 0040316
2016-01-25 08:50Brad KingAssigned To => Brad King
2016-01-25 08:50Brad KingStatusnew => resolved
2016-01-25 08:50Brad KingResolutionopen => fixed
2016-01-25 08:50Brad KingFixed in Version => CMake 3.5
2016-01-25 08:50Brad KingTarget Version => CMake 3.5
2016-01-27 09:50Brad KingNote Added: 0040332
2016-01-27 09:50Brad KingFixed in VersionCMake 3.5 => CMake 3.4.3
2016-01-27 09:50Brad KingTarget VersionCMake 3.5 => CMake 3.4.3
2016-06-10 14:21Kitware RobotNote Added: 0041274
2016-06-10 14:21Kitware RobotStatusresolved => closed

Notes
(0040282)
Brad King   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
2016-01-25 08:50   
Re 0015929:0040308: Great, thanks for testing!
(0040332)
Brad King   
2016-01-27 09:50   
This change has been merged back to 'release' and included in the 3.4.3 release.
(0041274)
Kitware Robot   
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.