[cmake-developers] Bug in Visual Studio generators

[Brad King]

On 04/08/2014 08:13 PM, Josh Green wrote:
> I have gone back and re-read the commit message of the commit that I
> linked earlier:
> 
>> Most CMake generators produce relative paths within the build tree and
>> full paths to files outside the build tree.  Make VS 10 and VS 11
>> project files consistent with this approach except for paths forced to
>> be relative to work around a VS 10 bug.
> 
> This commit message actually demonstrates a misunderstanding of why
> visual studio build files were using absolute paths.

No, it was just poorly worded.  Your analysis of the current logic
appears to be done under the assumption that ConvertPath is intended
to produce absolute paths if CMAKE_USE_RELATIVE_PATHS is off and
forceRelative is off.  It is not.  The forceRelative argument says
to always use a relative path instead of using the logic builtin to
the cmLocalGenerator::Convert method.  That logic produces a relative
path if it has no leading "../" sequence that raises above the source
or build tree, and otherwise produces a full path.

> Visual Studio needs absolute paths by default in order to handle the
> deep hierarchies that occur in many larger projects.

Yes.  This is explained in the WriteSources comment here:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmVisualStudio10TargetGenerator.cxx;hb=v3.0.0-rc3#l928

  // Visual Studio tools append relative paths to the current dir, as in:
  //
  //  c:\path\to\current\dir\..\..\..\relative\path\to\source.c
  //
  // and fail if this exceeds the maximum allowed path length.  Our path
  // conversion uses full paths outside the build tree to allow deeper trees.

> I have attached a patch that applies the relevant fix, and a comment
> to explain the reason why and avoid future regressions.

Your change makes WriteSources obey CMAKE_USE_RELATIVE_PATHS
but switches the default to use absolute paths.  This is a
reasonable proposal, but there may be other code paths that
use cmLocalGenerator::Convert with optional==false.

I'd like to understand why "../" paths are generated in
your use case.  Is it a relative path from one deep directory
within the build tree to another?  Or, are you placing the
build tree inside the source tree?

Thanks,
-Brad