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

René J.V. Bertin noreply at phabricator.kde.org
Wed Apr 4 17:13:46 UTC 2018

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.

  R32 KDevelop



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>

More information about the KDevelop-devel mailing list