(0040803)
Ben Boeckel (developer)
2016-04-04 10:29

This is due to the internal translation map. One fix is to change the Qt4 macros to not use relative paths (absolute paths should always work).

(0040805)
Maurizio Paolini (reporter)
2016-04-04 12:12

The way I worked around this issue is to use (from within the project folder)

cmake $(pwd -P) [options]

instead of

cmake . [options]

Does it make sense for cmake to remap the path given as argument into the corresponding realpath? (something like `realpath <arg>`)

(0040807)
Ben Boeckel (developer)
2016-04-04 12:51

It can do it, but there was a use case for keeping the logical name of both the build and source directories, but I think it was implemented without thinking of other use cases. It's on my list to fix, but has been low priority.

Basically, some machines have a per-machine symlink set up for home directories (think supercomputers and login nodes). So /home/user is a symlink to /mount/shared/hostA/home/user on login node "hostA", but /shared/hostB/home/user on "hostB". Depending on which machine you land on, the realpath is invalid, so instead the path you used to access it is considered "canonical".

To fix this, the following logic should be implemented (I think this works, but it might need some checking):

    common = commonpath(source, binary)
    realsrc = realpath(source)
    realbin = realpath(binary)
    realcommon = commonpath(realsrc, realbin)
    if relativepath(common, source) == relativepath(realcommon, realsrc) and relativepath(common, binary) == relativepath(realcommon, realbin)
       add_translation_entry(common, realcommon)

Basically, if all symlinks are above the common root of the source and binary directory, relative paths between the two trees are valid before and after realpath() on either end. Otherwise, the symlinks are important and the translation path cannot be added.

(0040808)
Maurizio Paolini (reporter)
2016-04-04 14:47

Makes sense...
What about a scenario in which a user creates her own symlink (e.g. to quickly access some involved path in her home) on top of the scenario that you describe? Wouldn't this
be a problem?

(0040809)
Ben Boeckel (developer)
2016-04-04 14:53

Only if you expect:

    cd binary
    cmake source

and

    cd realbin
    cmake realsrc

to work interchangeably (CMake might complain that CMAKE_HOME_DIRECTORY has changed between runs). If you always access it through the same logical path, CMake doesn't care. It's when you switch between real and logical that things might get weird. Not sure how best to fix that yet. Maybe CMAKE_HOME_DIRECTORY should just always be a realpath and the translation entry is purely a configure- and generate- time thing?

(0040810)
Maurizio Paolini (reporter)
2016-04-04 17:48

Uhm, and what about your original reference to Qt4? What macros are you referring to?
BTW, I reported your remark in QTBUG-51964

(0042975)
Kitware Robot (administrator)
2016-06-10 14:29

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
2016-04-01 13:36	Maurizio Paolini	New Issue
2016-04-04 10:29	Ben Boeckel	Note Added: 0040803
2016-04-04 12:12	Maurizio Paolini	Note Added: 0040805
2016-04-04 12:51	Ben Boeckel	Note Added: 0040807
2016-04-04 14:47	Maurizio Paolini	Note Added: 0040808
2016-04-04 14:53	Ben Boeckel	Note Added: 0040809
2016-04-04 17:48	Maurizio Paolini	Note Added: 0040810
2016-06-10 14:29	Kitware Robot	Note Added: 0042975
2016-06-10 14:29	Kitware Robot	Status	new => resolved
2016-06-10 14:29	Kitware Robot	Resolution	open => moved
2016-06-10 14:29	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Notes
(0040803) Ben Boeckel (developer) 2016-04-04 10:29	This is due to the internal translation map. One fix is to change the Qt4 macros to not use relative paths (absolute paths should always work).

(0040805) Maurizio Paolini (reporter) 2016-04-04 12:12	The way I worked around this issue is to use (from within the project folder) cmake $(pwd -P) [options] instead of cmake . [options] Does it make sense for cmake to remap the path given as argument into the corresponding realpath? (something like `realpath <arg>`)

(0040807) Ben Boeckel (developer) 2016-04-04 12:51	It can do it, but there was a use case for keeping the logical name of both the build and source directories, but I think it was implemented without thinking of other use cases. It's on my list to fix, but has been low priority. Basically, some machines have a per-machine symlink set up for home directories (think supercomputers and login nodes). So /home/user is a symlink to /mount/shared/hostA/home/user on login node "hostA", but /shared/hostB/home/user on "hostB". Depending on which machine you land on, the realpath is invalid, so instead the path you used to access it is considered "canonical". To fix this, the following logic should be implemented (I think this works, but it might need some checking): common = commonpath(source, binary) realsrc = realpath(source) realbin = realpath(binary) realcommon = commonpath(realsrc, realbin) if relativepath(common, source) == relativepath(realcommon, realsrc) and relativepath(common, binary) == relativepath(realcommon, realbin) add_translation_entry(common, realcommon) Basically, if all symlinks are above the common root of the source and binary directory, relative paths between the two trees are valid before and after realpath() on either end. Otherwise, the symlinks are important and the translation path cannot be added.

(0040808) Maurizio Paolini (reporter) 2016-04-04 14:47	Makes sense... What about a scenario in which a user creates her own symlink (e.g. to quickly access some involved path in her home) on top of the scenario that you describe? Wouldn't this be a problem?

(0040809) Ben Boeckel (developer) 2016-04-04 14:53	Only if you expect: cd binary cmake source and cd realbin cmake realsrc to work interchangeably (CMake might complain that CMAKE_HOME_DIRECTORY has changed between runs). If you always access it through the same logical path, CMake doesn't care. It's when you switch between real and logical that things might get weird. Not sure how best to fix that yet. Maybe CMAKE_HOME_DIRECTORY should just always be a realpath and the translation entry is purely a configure- and generate- time thing?

(0040810) Maurizio Paolini (reporter) 2016-04-04 17:48	Uhm, and what about your original reference to Qt4? What macros are you referring to? BTW, I reported your remark in QTBUG-51964

(0042975) Kitware Robot (administrator) 2016-06-10 14:29	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.

Relationships