Re: Some questions regarding LSP integration

On 10/02/22 23:23, Alexander Neundorf wrote:
> Hi,
>
> On Donnerstag, 10. Februar 2022 22:59:32 CET you wrote:
>> Hi,
>>
>>> On Donnerstag, 10. Februar 2022 06:55:19 CET Waqar Ahmed wrote:
>>>> Hi,
>>>>
>>>> Yes, that is more or less what clangd does.
>>>>
>>>>> (so this will often fail)
>>>> Yes, if there is no compile_commands.json found. And there can be
>>>> multiple build dirs with multiple different compile_commands.json
>>>> lying around (Think about people working on porting kde software to
>>>> Qt6, they may have 2 build dirs one for Qt5 and one for Qt6, both
>>>> having different compile_commands).
>>> yes, sure, or simply having a DEBUG and a RELEASE build, or any other
>>> differing build options in different build trees, e.g. using a
>>> system-provided
>>> library vs. the library coming from some 3rdparty/ directory.
>>>
>>> Modifying the contents of ${CMAKE_SOURCE_DIR} in some way feels wrong,
>>> it should be considered read-only for build tools (so different build
>>> trees don't interfer with each other).
>>>
>>> But if that's the only way how clangd works, then that's how it is.
>> It is at least the most easy way to get that tooling working properly.
>> Even more if you want to e.g. use the clang-format stuff just in some
>> random shell.
> I started looking at the code, I'll have a look what it would take to have one
> LSPClientServer per open cmake-based project (from the project plugin), and
> actually set the directory via clangd command line option.
> Then each build tree would, without any copying or symlinking, would get the
> correct build flags etc.
> But it will take some time until I get to do it.
>
> ...
It is actually already "almost" possible to achieve this by tweaking the server settings.  The 
plugins manual gives an example of how to use variables to launch a separate python lsp server per 
repo/project, and moreover aware of and adapted to a python virtual environment there (per that 
repo/project), see 
https://docs.kde.org/trunk5/en/kate/kate/kate-application-plugin-lspclient.html#lspclient-configuration.

In particular, this uses the variable expansion "%{Project:NativePath}".  So, along with details as 
in that example, "all" that remains is to have project/cmake/build (?) plugin define a variable, 
e.g. "%{Project:BuildPath}", and then that one can be used in configured "User Server Settings" in a 
command line argument to (clangd) server.

The default scenario and settings should preferably remain (supported), as there are also many cases 
where a single server across multiple repos is more convenient and efficient and in fact necessary 
(when working with various inter-related code repos, as opposed to a mono-repo).

Regards,
Mark