Notes
(0031536) David Cole (manager) 2012-11-13 07:16	Why does it matter if there's a trailing slash on the result or not? You can always append a "/" even if the directory name already ends in "/" to compose a new directory or file name under that one. If there are multiple consecutive slashes in a file name (other than a leading pair of slashes to indicate a network path) they will be considered the same as a single slash in the same spot. But we would recommend using a full path as the leading component when combining path fragments so that any operations done on the result are unambiguous.

(0031548) Janne Rönkkö (reporter) 2012-11-13 23:58	One reason would be that file( GLOB ... ) does not work if there is two slashes in the globbing expression. See the new example in the files-2.tar. The reason I'm using relative paths is that the software I'm developing uses both cygwin and windows tools when building making the absolute paths incompatible. I know that the real problem is the obscure development environment but for now that can not be changed. Of course I could keep two versions of those paths and work with those but then the CMake code in the build system would contain a lot of duplication that needs to be removed when the development environment has been cleaned up to work only with Windows tools on Windows. The issue can be overcome quite easily by using the function below but the current behaviour of CMake is quite inconsistent. function( relativePath TargetVarName FromDir ToFile ) file( RELATIVE_PATH relpath ${FromDir} ${ToFile} ) if( IS_DIRECTORY ${ToFile} ) string( REGEX MATCH ".*/$" match ${relpath} ) if( NOT "${match}" STREQUAL ${relpath} ) set( relpath "${relpath}/" ) endif() endif() set( ${TargetVarName} ${relpath} PARENT_SCOPE ) endfunction()

(0031549) Janne Rönkkö (reporter) 2012-11-14 00:04	I got my example all wrong. GLOB works with /full/path//* but not with ../path/*. I looked the prints the wrong way.

(0031550) Janne Rönkkö (reporter) 2012-11-14 00:21	The glob example was completely incorrect. That was not the reason for the build to fail when I found out that out of source tree builds were failing. The only reason was those missing slashes. Any way the point is that CMake currently behaves inconsistently. Also if the relative path ends up being "" adding slash to that gives you the root directory which does not work. That is also problem with the function I pasted above.

(0031556) David Cole (manager) 2012-11-14 11:00	So, what would you propose as the fix? I would say we should consistently return the same sort of string, without a trailing slash at the end. But I wonder if anybody is depending on the current behavior, or if they are testing the result to see if there's a trailing slash at the end. It would make me nervous to change this behavior, knowing there might be some code out there depending on the existing behavior. Would you think we could safely make this change without breaking anybody's code...?

(0031559) Janne Rönkkö (reporter) 2012-11-15 00:26	It's true that for consistency there should be no slash at the end of the path even though I would like that the slash would always be there (due to the empty path issue). You could add some kind of flag, for example, CMAKE_NO_TRAILING_SLASH_FOR_RELATIVE_PATHS that needs to be set before you get the new behaviour. And if the variable is not set and the file( RELATIVE_PATH ... ) is called you could print warning that the behaviour will change at some point, for example, when you release 2.10. This way there would be no immediate danger for breaking up builds and the users would get warning about to be changed behaviour. At least I was assuming that file( RELATIVE_PATH .. ) returns path ending with slash. The documentation does not say anything so I just had to rely what the output from the function was.

(0031567) David Cole (manager) 2012-11-16 08:53	To fix this bug, we should introduce a new CMake policy so that the old behavior remains in place until people update their minimum required CMake to a new version that contains the fix. This bug should be lower on our priority list for fixing, since there is an easy workaround, the "relativePath" function mentioned in 0013682:0031548

(0042149) Kitware Robot (administrator) 2016-06-10 14:28	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
2012-11-13 02:39	Janne Rönkkö	New Issue
2012-11-13 02:39	Janne Rönkkö	File Added: files.tar
2012-11-13 07:16	David Cole	Note Added: 0031536
2012-11-13 23:58	Janne Rönkkö	Note Added: 0031548
2012-11-13 23:58	Janne Rönkkö	File Added: files-2.tar
2012-11-14 00:04	Janne Rönkkö	Note Added: 0031549
2012-11-14 00:21	Janne Rönkkö	Note Added: 0031550
2012-11-14 11:00	David Cole	Note Added: 0031556
2012-11-15 00:26	Janne Rönkkö	Note Added: 0031559
2012-11-16 08:53	David Cole	Note Added: 0031567
2016-06-10 14:28	Kitware Robot	Note Added: 0042149
2016-06-10 14:28	Kitware Robot	Status	new => resolved
2016-06-10 14:28	Kitware Robot	Resolution	open => moved
2016-06-10 14:28	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships