On 04/09/2014 08:16 PM, Josh Green wrote:
> Thanks for your explanation of cmLocalGenerator::Convert.
> My source tree roughly looks like this:
> C:\dev\root\src\CMakeLists.txt -- root cmake lists file
> C:\dev\root\src\build\ -- This is the target location for build files
> to be placed.
> 
> I think by your definition, that means the build tree is inside the source 
> tree.
> Indeed, if I send the build files out to the 'root' directory, then
> absolute paths are generated.

Okay, that confirms things are working as expected with the current logic.

> Is there any documentation that describes this behaviour?

No.  These paths are internal implementation details for which no
guarantee is made and that users should not have to care about.
It is only due to the path limits that anyone ever notices.

> Why would cmake want to generate relative files by default?

The cmLocalGenerator::Convert method is used to process almost every
path written out by every generator.  For example, references to the
object files on a linker command line are produced by it.  Using
relative paths leads to much shorter command lines so OS limits on
command-line lengths are much farther away.  Often the relative paths
have no leading "../" at all.

> What is the difference between having the build tree inside the source
> tree, that it means the path generation behaviour needs to change?

That is only an unintentional side effect of the conversion logic.
We don't want "../" to escape from the source or build tree because
then it might step over a symbolic link or something.  When the build
tree is inside the source tree then relative paths can be generated
to refer to the source tree from the build tree without stepping
outside the source tree.

However, some folks do use the method I outlined in my first response
in this thread to generate relocatable .vcxproj files by post-processing
what CMake generates.  In order to minimize the filtering needed for
that use case it is reasonable to generate relative paths when we can.

> Perhaps using this method isn't the best choice for the Visual Studio
> generators?
> I think, under Visual Studio the choice of absolute/relative paths
> should be mostly driven by this 260 character limit

The current logic (produced by commit range a7d0fb14..d931ce9f) is:

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

and does use full paths when necessary to fit under the character
limit, but only as part of the VS 10 special case.  Perhaps we need
a code path there for other VS versions to check the character limit
too.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Reply via email to