MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015930CMakeCMakepublic2016-01-21 11:362016-06-10 14:31
ReporterBruce Pascoe 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformWindowsOSWindows 10OS Version
Product Version 
Target VersionFixed in Version 
Summary0015930: MSVC project switched to Windows XP toolset won't compile
DescriptionMSVC projects created by CMake explicitly add the detected Windows SDK to the include paths. Normally this doesn't cause an issue, however if the project's Platform Toolset is then switched from "Visual Studio 201x" to "Visual Studio 201x - Windows XP" it will no longer compile.

The cause of this is that the Windows XP toolchain uses a different SDK version, installed in a different location from the default.

The project can be made to compile at this point by removing the Windows SDK from the include paths, which allows the IDE (actually MSBuild) to select the correct SDK on its own.
Steps To Reproduce* Generate a Visual Studio project using CMake
* Open Project Properties -> General in MSVC
* Change the Platform Toolset to the Windows XP version.
* Try to build the project.
Additional Information
TagsNo tags attached.
Relationships
related to 0015929closed Brad King "Could not find an appropriate version of the Windows 10 SDK" 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2016-01-21 11:36Bruce PascoeNew Issue
2016-01-21 11:51Brad KingRelationship addedrelated to 0015929
2016-01-21 11:55Brad KingNote Added: 0040293
2016-01-21 14:42Bruce PascoeNote Added: 0040297
2016-01-21 14:42Bruce PascoeNote Edited: 0040297bug_revision_view_page.php?bugnote_id=40297#r2010
2016-01-22 08:17Brad KingNote Added: 0040298
2016-01-23 01:07Bruce PascoeNote Added: 0040309
2016-01-23 01:07Bruce PascoeNote Edited: 0040309bug_revision_view_page.php?bugnote_id=40309#r2012
2016-01-23 01:07Bruce PascoeNote Edited: 0040309bug_revision_view_page.php?bugnote_id=40309#r2013
2016-01-23 01:07Bruce PascoeNote Edited: 0040309bug_revision_view_page.php?bugnote_id=40309#r2014
2016-01-23 01:08Bruce PascoeNote Edited: 0040309bug_revision_view_page.php?bugnote_id=40309#r2015
2016-01-25 08:50Brad KingNote Edited: 0040297bug_revision_view_page.php?bugnote_id=40297#r2016
2016-01-25 08:51Brad KingNote Edited: 0040309bug_revision_view_page.php?bugnote_id=40309#r2017
2016-01-25 08:56Brad KingNote Added: 0040318
2016-01-25 09:09Bruce PascoeNote Added: 0040319
2016-01-25 09:36Brad KingNote Added: 0040320
2016-01-25 09:39Bruce PascoeNote Added: 0040321
2016-01-25 11:28Brad KingNote Added: 0040323
2016-01-25 11:29Brad KingNote Added: 0040324
2016-06-10 14:29Kitware RobotNote Added: 0042918
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0040293)
Brad King   
2016-01-21 11:55   
Try configuring a fresh build tree with "-DCMAKE_SYSTEM_VERSION=5.1". That tells the VS 2015 generator that we want to target a different version of Windows than the host.

We'll also have to look at teaching the generator that when CMAKE_GENERATOR_TOOLSET is v140_xp then it should not try to use a Windows 10 SDK.
(0040297)
Bruce Pascoe   
2016-01-21 14:42   
(edited on: 2016-01-25 08:50)
Re 0015930:0040293 - Thanks for the tip about CMAKE_SYSTEM_VERSION=5.1, that works around issue 0015929, however it doesn't solve the bug here - changing the toolset to v140_xp prevents compilation until "C:\Program Files (x86)\Windows Kits\8.1\Include\um" is removed from Additional Include Directories.
(0040298)
Brad King   
2016-01-22 08:17   
Re 0015930:0040297: AFAIK CMake is not adding any of the system include directories. Check the actual content of the generated .vcxproj file in a text editor to see whether they appear.
(0040309)
Bruce Pascoe   
2016-01-23 01:07   
(edited on: 2016-01-25 08:51)
Re 0015930:0040298: You're right. I was building Allegro 5 and it turns out their scripts explicitly add the SDK path while looking for the DirectX libs. False alarm.

edit: How do I get the reply number to be a link?
(0040318)
Brad King   
2016-01-25 08:56   
Re 0015930:0040309:

> False alarm

Okay, thanks. Is there still an issue here? My proposal in 0015930:0040293 may still be relevant.

> How do I get the reply number to be a link

Use "~#####" where "~" is literal and "#####" is the comment number (ignoring the issue number to which it is attached). I edited your previous notes in this issue to fix the links.
(0040319)
Bruce Pascoe   
2016-01-25 09:09   
The only change I could possibly suggest is, for MSVC generators, to explicitly check if the Windows SDK path is being added to the include directories and leave it out of the generated project file. Don't know if that would break any builds in edge cases though.

As for that proposal, I don't know - the Allegro project doesn't include an option to use the XP toolchain in its build system so I have to go into the MSVC solution afterwards and change that manually. Which is how I ran into this problem.
(0040320)
Brad King   
2016-01-25 09:36   
Re 0015930:0040319: FYI, CMake allows the toolchain to be specified like this:

 cmake ..\src -G "Visual Studio 14 2015" -T v140_xp
(0040321)
Bruce Pascoe   
2016-01-25 09:39   
Is there a way to set the toolchain in cmake-gui? I usually use that for Allegro, since it has so many configuration options.
(0040323)
Brad King   
2016-01-25 11:28   
Re 0015930:0040321: As of CMake 3.4 one can use the "Add Entry" button when creating a fresh build tree to add a "CMAKE_GENERATOR_TOOLSET" entry with the desired value. CMake 3.5 (and the nightly binary) introduces a widget for this:

 cmake-gui: Add option to specify generator toolset
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2b958a20 [^]
(0040324)
Brad King   
2016-01-25 11:29   
Re 0015930:0040323: Oh, and the toolset must be selected when first creating a build tree and should not later be changed for that tree.
(0042918)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

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.