View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013666CMakeCMakepublic2012-11-09 01:482016-05-02 08:30
ReporterAndreas Mohr 
Assigned To 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformPCOSWindowsOS Version
Product VersionCMake 2.8.10.1 
Target VersionCMake 3.5Fixed in VersionCMake 3.5 
Summary0013666: CMake fails to support existing custom VS_GLOBAL_* properties in VS10 (ProjectExtensions -> VisualStudio -> UserProperties)
DescriptionWhile working on related functionality in vcproj2cmake, I noticed that while CMake has VS_GLOBAL_* properties (which on VSx side are different things: official *or* custom!) which are properly being generated into VS7 Globals section,
in the VS10 generator there seems to be nothing done about it despite it seeming to be expected to go into the ProjectExtensions element (VisualStudio -> UserProperties sub elements).

A popular example of it would be the RESOURCE_FILE setting (or perhaps also QtVersion?).

From some Q&D analysis it appears that the properties that CMake manages (improperly lumps together!!) as VS_GLOBAL_* are managed by VS in this way:
VS7/8: project-global attribute keys are the "official"/"fixed" VS_GLOBAL_* values, whereas keys in Globals element are any user-custom values
VS10: element keys in Globals element are the "official"/"fixed" VS_GLOBAL_* values, whereas keys in UserProperties (i.e. ProjectExtensions) element are any user-custom values

Severity major since failing to generate the UserProperties section from all non-official user-custom VS_GLOBAL_* properties kills all user-supplied project properties on VS10, thus possibly causing major grief on user side, and it would be rather very easy to correct.

Unless UserProperties section content happened to in fact be something different on VS10 and these properties are not supposed to be generated there... (would probably need some more analysis of known content in public sample project files)

Thanks for listening! :)
TagsNo tags attached.
Attached Files

 Relationships
related to 0008707closedDavid Cole Add support for global variables in Visual Studio generator 
related to 0012586closedBrad King [patch] CMake does not support Visual Studio projects types or dotnet references with managed C++ 

  Notes
(0031508)
Brad King (manager)
2012-11-09 08:21

 The VS_GLOBAL_* feature was user-contributed in issues 0008707 and 0012586.

Please look at constructing a patch (on latest master) to implement the feature for VS >= 10.
(0040192)
Brad King (manager)
2016-01-11 13:11

 Relevant mailing list thread:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15370/focus=15387 [^]
(0040208)
Brad King (manager)
2016-01-12 13:37

 Patch from mailing list thread linked by 0013666:0040192 applied here:

 VS: Implement VS_GLOBAL_* target properties in VS 2010+
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af39f115 [^]
(0041001)
Robert Maynard (manager)
2016-05-02 08:30

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2012-11-09 01:48 Andreas Mohr New Issue
2012-11-09 08:18 Brad King Relationship added related to 0008707
2012-11-09 08:18 Brad King Relationship added related to 0012586
2012-11-09 08:21 Brad King Note Added: 0031508
2016-01-11 13:11 Brad King Note Added: 0040192
2016-01-12 13:37 Brad King Note Added: 0040208
2016-01-12 13:38 Brad King Status new => resolved
2016-01-12 13:38 Brad King Resolution open => fixed
2016-01-12 13:38 Brad King Fixed in Version => CMake 3.5
2016-01-12 13:38 Brad King Target Version => CMake 3.5
2016-05-02 08:30 Robert Maynard Note Added: 0041001
2016-05-02 08:30 Robert Maynard Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team