D22710: ensure clangd is started for each project on it's own

[Mark Nauwelaerts]

mnauwelaerts added a comment.


  There are 2 stages of consideration here.  One of (desired) functionality, and then how to implement it.
  
  Regarding functionality, my configuration uses symlinks (to compile_commands.json) as recommended by upstream clangd and uses $HOME for the server root and no "compilationDatabasePath" whatsoever.  In particular, I need only 1 clangd instance, and it can handle multiple projects fine by using the symlinks to find what it needs (e.g. the compilation database).  By forcing it with custom code that adds a "compilationDatabasePath" it then indeed starts to go wrong as it would try to use that db also when it should not.  So then it becomes necessary to start several instances to be able to force them independently.  All in all, IMO it is easier and (very) advisable not to hand-hold either clangd or users/developers (with custom "compilationDatabasePath").  Of course, this would come at the expense of users/developers then having to deal with symlinks themselves, which is after all the upstream recommendation.  I am also still (silently but fiercely) hoping that 1 (shared) clangd instance will be able to find a definition (asked in one project's file) which is present in another project.  When using separate instances, there seems no chance of such happening.  However, it could be argued we might nevertheless want to provide a custom "service" that makes it not necessary to add the symlink ...
  
  ... in which case we are passing into the implementation part of that "service".  Such is necessarily pretty custom and server specific.  In this case these changes are as good as that could get, as that is a slippery/tricky slope that hopefully does not grow to involve other servers ...
  
  However, there is a minor problem in the the default configuration changes.  The changes there will now always force a separate server per project, which as mentioned above is not really required for clangd (depends on how you configure it), but it is not needed for python's pyls (and probably not for others either).  clangd custom's override is rather the exception.  So makeServerConfig should rather accept a "const QJsonValue & root", and be called with a string for clangd then, but an empty (null) for pyls as it was before (note null != QString()).

REPOSITORY
  R40 Kate

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

To: cullmann, dhaumann, mnauwelaerts
Cc: kwrite-devel, domson, michaelh, ngraham, demsking, cullmann, sars, dhaumann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20190724/7f55fd1a/attachment-0001.html>