MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0016047CMakeCMakepublic2016-04-01 13:362016-06-10 14:31
ReporterMaurizio Paolini 
Assigned ToKitware Robot 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake 3.4.1 
Target VersionFixed in Version 
Summary0016047: automoc generates wrong #includes for projects in a symlinked path
Descriptionproject "kig" uses cmake and automoc.
My local copy of the git sources are located in a folder that I reach following a symlink
(it resides in a local partition whereas my home is on an NFS-mounted filesystem).
after a cmake and then a "make", the generated "moc*" files contain
an "#include" like this:

#include "../../../../../misc/euclide/paolini/Git/kdeedu/kig/modes/popup/popup.h"

There is a wrong number of ".." and the path does not work.
using "make VERBOSE=1 kigpart_automoc" it turns out that the following command is issued:

/usr/lib/qt5/bin/moc -I/home/matem/paolini/Git/kdeedu/kig/modes [...] -o /home/matem/paolini/Git/kdeedu/kig/moc_popup.cpp /home/misc/euclide/paolini/Git/kdeedu/kig/modes/popup/popup.h

where the [...] part contains many more -I and various options. Notice that "/home/matem/paolini/Git/" and "/home/misc/euclide/paolini/Git/" point to the same place, the first through the symlink "Git", the second is the physical path.
I guess that then "moc" tries hard to walk (with a relative path) from
one path to the other, but there is no way to successfully climb up
a path with a symlink in it using the ".." directory.

This problem was previously reported in the QT bug tracker
https://bugreports.qt.io/browse/QTBUG-51964 [^]

Steps To Reproduce$ mkdir -p a/b
$ ln -s a/b a.lnk
$ cd a.lnk
$ <create a cmake project here that uses automoc>
$ cd <project>
$ cmake . [...]
$ make
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2016-04-01 13:36Maurizio PaoliniNew Issue
2016-04-04 10:29Ben BoeckelNote Added: 0040803
2016-04-04 12:12Maurizio PaoliniNote Added: 0040805
2016-04-04 12:51Ben BoeckelNote Added: 0040807
2016-04-04 14:47Maurizio PaoliniNote Added: 0040808
2016-04-04 14:53Ben BoeckelNote Added: 0040809
2016-04-04 17:48Maurizio PaoliniNote Added: 0040810
2016-06-10 14:29Kitware RobotNote Added: 0042975
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0040803)
Ben Boeckel   
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   
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   
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   
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   
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   
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   
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.