D11921: CMake Server: Reuse existing build directory path when available

[René J.V. Bertin]

rjvbb accepted this revision.
rjvbb added a comment.
This revision is now accepted and ready to land.


  >   @rjvbb does this solve issues you are having and trying to workaround with https://phabricator.kde.org/D7930 ?
  
  The problem I try to solve with D7930 <https://phabricator.kde.org/D7930> goes beyond having to rebuild everything every time: it is about code parsing failing when auto-generated (.moc) files use relative include paths. This can even fail during an actual build if the symlinked path doesn't have the same number of subdirectories relative to the root as the normalised path.
  
  It looks like this patch should help with that issue, provided that the CMake stores the actual, normalised path in `CMAKE_CACHEFILE_DIR`, does it?
  
  I'm not noticing any different with and without this patch applied, on Mac. Not really surprising as the system always normalises paths, so applications cannot obtain a PWD path that contains symlinks.
  
  > I've never used CMAKE_CACHEFILE_DIR before and am not sure if it's OK to use it like this.
  
  According to the docs `This [variable] is the same as CMAKE_BINARY_DIR` and thus should be the same path as KDevelop's $build.dir setting. The change should be safe so I agree with Sven: apply this to 5.2 but after the 5.2.2 release. Or better yet, delay that release a couple of days so more people can test and (many) more users can benefit from the fix a lot sooner.

REPOSITORY
  R32 KDevelop

BRANCH
  master

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

To: mwolff, #kdevelop, rjvbb
Cc: kfunk, brauch, apol, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180404/2359cdca/attachment.html>