D9297: Fix #387391: Random responses from the C/C++ language support

[Venca B Spam]

vbspam added a comment.


  > Hmm. There's a comment in the line above which states it explicitly uses canonicalFilePath to avoid issues with symlinks.
  
  I 100% agree, that is why I am cautious about this, therefore my question above.
  
  > If we resolve symlinks like you suggest, there will be situations like files which are part of a project but for which the project's root directory is not a prefix of the file path.
  
  My test case scenario (https://bugs.kde.org/attachment.cgi?id=109155) is covering this. I have one CMake project inside, I have other (LibBar) which is "physically" outside and symlinked inside.
  
  This test scenario works well with the fix now. What I found is that canonicalFilePath() (in other words unique path pointing to the original/physical file - outside the project root), does not work well with KDevelop call which uses absoluteFilePath() (in other words absolute path visually appearing as absolute path to the symlink (not to the target file) - so to be inside project).
  
  > Are we somewhat sure this doesn't break in other places?
  
  It works for normal files, it also works for both absolute(don't get confused with absoluteFilePath above which which is this term not about) and relative symlinks.
  
  Thank you for the question! You are right, I forgot to test symlinks to resources physically stored inside the project root. I quickly created such scenario now which can be found here (https://bugs.kde.org/attachment.cgi?id=109341). I reveals that it does not work, I believe however that KDevelop does not properly build the project tree. My new test scenario links "LibAnotherBar" to the project root from the "InsideProjectRoot/LibAnotherBar". The build system is instructed to use the LibAnotherBar (by cmake add_subdirectory(LibAnotherBar) ), KDevelop however assumes the build system meant InsideProjectRoot/LibAnotherBar" and shows the project treeview populated with the "InsideProjectRoot/LibAnotherBar" instead requested "LibAnotherBar".
  
  I did check the CMake server response and it shows properly generated build system (please check attached test4.json F5543815: test4.json <https://phabricator.kde.org/F5543815>)

REPOSITORY
  R32 KDevelop

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

To: vbspam, #kdevelop
Cc: brauch, kdevelop-devel, vbspam, njensen, geetamc, Pilzschaf, akshaydeo, surgenight, arrowdodger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20171212/68635290/attachment.html>