MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012570CMakeCMakepublic2011-11-10 11:212012-12-03 07:46
ReporterNiels Dekker 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformVisual Studio 2010OSMicrosoft WindowsOS Version
Product VersionCMake 2.8.6 
Target VersionCMake 2.8.9Fixed in VersionCMake 2.8.9 
Summary0012570: VS10 property pages for single source file gone
DescriptionI described this issue at "[CMake] Visual Studio 10 property pages for single source file gone with CMake 2.8.5 and 2.8.6", http://www.cmake.org/pipermail/cmake/2011-November/047345.html [^] (below here). The issue was confirmed by Domagoj Saric and J Decker.

----- Original Message -----
From: "Niels Dekker - address until 2014"
To: <cmake at cmake.org>
Sent: Thursday, November 10, 2011 16:14
Subject: [CMake] Visual Studio 10 property pages for single source file gone with CMake 2.8.5 and 2.8.6
---------------------------------------------------------------------------
When Visual Studio 10 vcxproj files are generated by CMake 2.8.5 or 2.8.6,
it is typically impossible to view the C/C++ properties of a single source
file. CMake 2.8.0 to 2.8.4 do not seem to have this issue. It looks like the
issue is caused by the fact that CMake 2.8.5 started storing the absolute
path names of the source files (even when CMAKE_USE_RELATIVE_PATHS is ON).

Is that a known issue?

Visual Studio 10 does not allow viewing the C/C++ properties of source files
that are listed by their absolute path names. See VS10 bug report 635294,
"Using absolute path in ClCompile item prevents property pages from
showing", by Niels M Hansen, 1/9/2011:
https://connect.microsoft.com/VisualStudio/feedback/details/635294/using-absolute-path-in-clcompile-item-prevents-property-pages-from-showing [^]

However, it seems like Visual Studio 10 *does* correctly support absolute
path names *without* drive letter! Would it be possible for CMake to write
the source file names *without* the drive letter, when it generates Visual
Studio 10 vcxproj files? (Especially when the generated vcxproj files are
located at the same drive as the source files.)
---------------------------------------------------------------------------
Steps To ReproduceCreate a file named "source.cpp" and a very simple CMakeLists.txt:

  project(foo)
  cmake_minimum_required(VERSION 2.8)
  add_executable(foo source.cpp)

Suppose both files are located at the directory "D:\dir". Generate a Visual Studio 10 project, using CMake 2.8.5 or 2.8.6. The generated project file, "foo.vcxproj", will have a line saying:

  <ClCompile Include="D:\dir\source.cpp" />

Open the generated solution file, "foo.sln", using Visual Studio 10. Right-click "source.cpp" within the Solution Explorer of Visual Studio, select Properties, and try to view the C/C++ Property Pages. Unfortunately, nothing is displayed!

Additional InformationVisual Studio appears to work fine when the drive letter ('D:') is removed from the source file name ("D:\dir\source.cpp"), in both foo.vcxproj and foo.vcxproj.filters. In general, I think removing the drive letter from the source file paths is fine, as long as the build directory and the source file paths have the same drive letter.
TagsNo tags attached.
Relationships
related to 0013406closed Kitware Robot Absolute path when generating VS 2010 project files does not work 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-11-10 11:21Niels DekkerNew Issue
2011-11-10 14:25Brad KingNote Added: 0027749
2011-11-10 14:29Brad KingNote Added: 0027750
2011-11-10 17:05Niels DekkerNote Added: 0027751
2011-11-10 17:19Brad KingNote Added: 0027752
2011-11-10 17:19Brad KingAssigned To => Brad King
2011-11-10 17:19Brad KingStatusnew => assigned
2011-11-11 07:37Niels DekkerNote Added: 0027756
2011-11-11 09:02Brad KingNote Added: 0027757
2011-11-11 17:25Niels DekkerNote Added: 0027785
2011-11-14 10:16Brad KingNote Added: 0027799
2011-11-14 11:08Niels DekkerNote Added: 0027800
2011-11-14 12:53Niels DekkerNote Edited: 0027800bug_revision_view_page.php?bugnote_id=27800#r451
2012-01-13 10:52Brad KingNote Added: 0028290
2012-01-13 10:55Brad KingNote Added: 0028291
2012-01-13 10:55Brad KingAssigned ToBrad King =>
2012-01-13 10:55Brad KingStatusassigned => backlog
2012-04-27 05:09asibilevNote Added: 0029355
2012-04-27 15:06Brad KingAssigned To => Brad King
2012-04-27 15:06Brad KingStatusbacklog => assigned
2012-04-27 15:06Brad KingTarget Version => CMake 2.8.9
2012-04-27 15:06Brad KingNote Added: 0029359
2012-04-30 08:07Brad KingStatusassigned => resolved
2012-04-30 08:07Brad KingFixed in Version => CMake 2.8.9
2012-04-30 08:07Brad KingResolutionopen => fixed
2012-05-03 19:12David ColeNote Added: 0029396
2012-06-12 16:15Brad KingNote Added: 0029670
2012-06-12 16:16Brad KingNote Edited: 0029670bug_revision_view_page.php?bugnote_id=29670#r668
2012-07-16 09:06Brad KingRelationship addedrelated to 0013406
2012-12-03 07:46David ColeNote Added: 0031805
2012-12-03 07:46David ColeStatusresolved => closed

Notes
(0027749)
Brad King   
2011-11-10 14:25   
Here are some commits from between 2.8.4 and 2.8.5 that appear relevant:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed0075bd [^]
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=38368d52 [^]
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=945f2c22 [^]

I tested this with VS 11 and it appears to be okay with the full paths.

I tried hand-editing a vcxproj file for VS 10 and changing the full paths to the UNC form:

  \\?\c:\full\path\to\source.cpp

The project loads and the property pages appear. I have not tested further.
(0027750)
Brad King   
2011-11-10 14:29   
Reference on UNC paths:

  http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath [^]
(0027751)
Niels Dekker   
2011-11-10 17:05   
Thanks Brad. Indeed I do get those property pages when the source file is specified by such a UNC path. Unfortunately, VS10 does not seem to be able to compile, or even open a file by its UNC path. The IDE tells me: "Illegal characters in path". And the compiler:

1>------ Build started: Project: msvc10proj, Configuration: Debug Win32 ------
1>Error: Invalid URI: The hostname could not be parsed.

If you don't get such errors, I'll double-check the UNC trick tomorrow (at another computer).
(0027752)
Brad King   
2011-11-10 17:19   
I never tested farther than whether the property pages show up. I'm not surprised the build doesn't work. The properties probably work because the UNC path starts in a slash.

I'm working on some internal cleanup needed to distinguish between VS 10 and VS 11 at the points in the code that matter for this. After that we can try VS10-specific workarounds like leaving off the drive letter.
(0027756)
Niels Dekker   
2011-11-11 07:37   
I'm sorry to say leaving off the drive letter won't solve the problem. (I suggested doing so, but I was wrong.) When there is no drive letter specified, Visual Studio assumes that the source files are located on the drive of the current working directory. This may not be the directory of the project! If I open a solution "D:\dir\foo.sln" by double-clicking foo.sln, the current directory is D:\dir. But if I start Visual Studio from the Start Menu, the current directory may be "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE", even after opening "D:\dir\foo.sln". In that case, the IDE will try to open "\dir\source.cpp" from the C: drive. :-(

I do believe this issue would be solved by having the path names of the source files relative to the vcxproj file. In fact I would have hoped CMAKE_USE_RELATIVE_PATHS=ON to do so. But I guess fixing CMAKE_USE_RELATIVE_PATHS is a lot of work, especially after having seen report 0012563, "CMAKE_USE_RELATIVE_PATHS should be removed from the documentation", by Robert Pollak. http://public.kitware.com/Bug/view.php?id=12563 [^]
(0027757)
Brad King   
2011-11-11 09:02   
As of CMake 2.8.4 we used relative paths. However, some projects had problems because VS does this with a relative path:

  c:\path\to\directory\with\project\file\..\..\..\relative\path\on\top\of\that\to\source.cpp

and then fails because the total string is over 250 characters or so even though the collapsed full path would be well under the limit.

So, we have a trade-off between severe limitations on the allowed path length to source and build trees ("c:\Documents and Settings\MyUser" does not help there) and allowing users to see the property dialogs. I'm inclined to favor the latter.
(0027785)
Niels Dekker   
2011-11-11 17:25   
Hmmm... it's a pity that Visual Studio doesn't deal with relative path names in a more clever way. I recently had a similar problem with an #include statement, which 'included' a header file through a path just below MAX_PATH, but still too long for Visual C++ (very much like https://connect.microsoft.com/VisualStudio/feedback/details/409997/relative-path-problem-in-vs2005 [^] reported by Gurpreet Singh Sachdeva).

Anyway, it looks like I can work around this issue by accessing the .sln file via a different drive letter, for example by using 'stubst', as suggested by John Drescher at http://www.cmake.org/pipermail/cmake/2011-November/047387.html [^] As far as I can see right now, this workaround is acceptable to me.

Thanks again!
(0027799)
Brad King   
2011-11-14 10:16   
Here are two patches for the cleanup mentioned in 0012570:0027752:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1be4b6f4 [^]
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c92ffece [^]

The first one actually fixes a regression for VS 7.1 introduced by your patch for issue 0012504 that I accidentally discovered while working on this.
(0027800)
Niels Dekker   
2011-11-14 11:08   
(edited on: 2011-11-14 12:53)
Thanks, Brad! I'm sorry for the VS 7.1 regression caused by my patch of issue 0012504. (I haven't got VS 7.1 installed anymore.) But I'm glad you made the VS versions properly LessThanComparable!
(0028290)
Brad King   
2012-01-13 10:52   
I forgot to update this issue to explain that commit 1be4b6f4 mentioned in 0012570:0027799 itself introduced a regression. It was discovered during the 2.8.7 release candidate cycle and fixed here:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6571f465 [^]
(0028291)
Brad King   
2012-01-13 10:55   
We are still stuck with the trade-off mentioned in 0012570:0027757 so I'm moving this to the backlog for now.
(0029355)
asibilev   
2012-04-27 05:09   
How can I workaround this with 2.8.8, without mapping drives?
I've tried to use - set( CMAKE_USE_RELATIVE_PATHS ON )
but got no effect, VC projects still with absolute paths.
May be there is already any hotfix for MSVC 2010?
(0029359)
Brad King   
2012-04-27 15:06   
After four commits to cleanup and refactor the VS 10 generator so we can send all source paths through a single conversion function:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f2d9d2d [^]
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c2ba6ba4 [^]
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4248132e [^]
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2e7c7ae [^]

I've committed a fix to this issue:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d931ce9f [^]

Now we use relative paths whenever possible so that property dialogs appear. When not possible due to length problems we use a full path and produce a warning at the end of generation that explains the problem and suggests use of shorter directory paths.
(0029396)
David Cole   
2012-05-03 19:12   
More information about other possible ways to see a similar error within Visual Studio:

  http://support.microsoft.com/kb/2516078 [^]

(That one deals with references between projects, though, not source files.)

Something to watch out for, and yet another reason to keep file and directory names as short as possible when Windows is a target platform.
(0029670)
Brad King   
2012-06-12 16:15   
(edited on: 2012-06-12 16:16)
It appears that the VS 11 RC introduces a similar problem that did not exist in the VS 11 developer preview:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/42614 [^]
 https://connect.microsoft.com/VisualStudio/feedback/details/748640 [^]
(0031805)
David Cole   
2012-12-03 07:46   
Closing resolved issues that have not been updated in more than 4 months.