View Issue Details [ Jump to Notes ] [ Print ]
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.
TagsNo tags attached.
Attached Files

 Relationships
related to 0015929closedBrad King "Could not find an appropriate version of the Windows 10 SDK" 

  Notes
(0040293)
Brad King (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (manager)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2016-01-21 11:36 Bruce Pascoe New Issue
2016-01-21 11:51 Brad King Relationship added related to 0015929
2016-01-21 11:55 Brad King Note Added: 0040293
2016-01-21 14:42 Bruce Pascoe Note Added: 0040297
2016-01-21 14:42 Bruce Pascoe Note Edited: 0040297
2016-01-22 08:17 Brad King Note Added: 0040298
2016-01-23 01:07 Bruce Pascoe Note Added: 0040309
2016-01-23 01:07 Bruce Pascoe Note Edited: 0040309
2016-01-23 01:07 Bruce Pascoe Note Edited: 0040309
2016-01-23 01:07 Bruce Pascoe Note Edited: 0040309
2016-01-23 01:08 Bruce Pascoe Note Edited: 0040309
2016-01-25 08:50 Brad King Note Edited: 0040297
2016-01-25 08:51 Brad King Note Edited: 0040309
2016-01-25 08:56 Brad King Note Added: 0040318
2016-01-25 09:09 Bruce Pascoe Note Added: 0040319
2016-01-25 09:36 Brad King Note Added: 0040320
2016-01-25 09:39 Bruce Pascoe Note Added: 0040321
2016-01-25 11:28 Brad King Note Added: 0040323
2016-01-25 11:29 Brad King Note Added: 0040324
2016-06-10 14:29 Kitware Robot Note Added: 0042918
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team