D7930: Kdevelop CMake plugin : use canonical paths to build.dir

[René J.V. Bertin]

rjvbb added a comment.


  In https://phabricator.kde.org/D7930#148980, @mwolff wrote:
  
  > You need to provide us with a way to setup a project to trigger this problem, then one can build a unit test out of it.
  
  
  See below. If I'm right, you could write a unittest that sets up a project of minimum complexity (but still requiring moc, possibly uic and generating config.h files) in the regular fashion. Then, set up another access path to the build directory using symlinks, one that goes through a different number of subdirs (simply /tmp/link-to-build.dir?). A make inside that shortcut build.dir will likely fail without canonicalisation, and then so will the parser.
  
  > So, if it breaks for you, how come?
  
  If I read this correctly, you have separate trees for the source directories and for the builds which seem to live on an (external?) SSD, and symlinks to those trees under your home directory.
  It's not easy to read but if I'm not mistaken you get into the build directories via the same number of subdirectories under /ssd and /home, and the names are equal too (except for build vs. build-dbg).
  
  IOW, a relative path to a header like the one shown in my previous comment will work regardless whether you're in the canonical/physical PWD, or in the PWD that includes a symlink. That's not my case, and you may run into problems too when you do
  
    > ln -s /ssd/milian/projects/kf5/build-dbg/extragear/kdevelop/kdevelop /tmp/build.dir
    > cd /tmp/build.dir
    > pwd
    /tmp/build.dir
    > make
  
  Here's my current understanding, somewhat deeper than a few days ago. Simplifying the paths a little bit, I have
  
  source: `/home/bertin/src/kf5/kdevelop-git`
  
  work dir:
  `/opt/local/var/build/tree1/kf5-kdevelop/work`
  
  containing
  `/opt/local/var/build/tree1/kf5-kdevelop/work/kdevelop` -> `/home/bertin/src/kf5/kdevelop-git`
  `/opt/local/var/build/tree1/kf5-kdevelop/work/build` : configured for /opt/local/var/build/tree1/kf5-kdevelop/work/kdevelop
  
  and my shortcut
  `/home/bertin/src/kf5/kdevelop-work` -> `/opt/local/var/build/tree1/kf5-kdevelop/work`
  
  So yes, my source directory accessed via a symlink too, but I don't think that is relevant for the issue (note though I'm not proposing to canonicalise the source directory even if doing it via KDevelop::Path didn't reveal any effects).
  
  in a nutshell, my configure+build script does the equivalent of
  
    source.dir=/opt/local/var/build/tree1/kf5-kdevelop/work/kdevelop
    build.dir=/opt/local/var/build/tree1/kf5-kdevelop/work/build
    
    if configuring ;then
        (cd ${build.dir} && cmake $OPTIONS ${source.dir})
    fi
    if building ;then
        (cd ${build.dir} && make)
    fi
  
  As I said, I rarely if ever build from inside KDevelop, and even my "official" cmake runs are made through those scripts in order to be certain that everything is set up as I want. I think my issue is above all related to the initial build steps where moc is being run, and possibly also the direct generation of certain headerfiles which aren't present after just running cmake. It will make a difference if you try to access these from `/home/bertin/src/kf5/kdevelop-work/build` or `/opt/local/var/build/tree1/kf5-kdevelop/work/build`, as long as they're generated and searched for using relative paths and those paths aren't updated as a function of that work directory.
  
  When all is said and done, `/home/bertin/src/kf5/kdevelop-work/build` is not the same path as `/opt/local/var/build/tree1/kf5-kdevelop/work/build`, despite the fact that they both point to the same location. The crucial difference is in the recursion level under the root. City-block distance I think one could call it. (Insert some relevant quip about the roads to Rome here.)
  
  Note that I never had any issues as long as I could prevent KDevelop from invoking cmake directly by ensuring I generate my own compile_commands.json file (when not doing builds, that is).
  
  I realise one could say "just don't use KDevelop that way" but I'd hope to think we agree that it shouldn't be possible to break things with something which in the end is so trivial. It corresponds to using KDevelop to working on packages that have to build through some build/distribution system (think Gentoo Prefix or pkgsrc) so it shouldn't be a complete fringe use case.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D7930

To: rjvbb, #kdevelop, apol
Cc: flherne, mwolff, apol, kdevelop-devel, geetamc, Pilzschaf, akshaydeo, surgenight, arrowdodger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20170926/4833228e/attachment.html>