Some questions regarding LSP integration

Alexander Neundorf neundorf at
Thu Feb 10 21:55:24 GMT 2022


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.

> So, automating this will not work
> for all scenarios. We currently have a solution in works which is:
> Implementing basic CMake support. One of the features is to
> automatically copy the compile_commands.json file to the root dir of
> the project from the "active" build directory / cmake preset. This
> will solve the problem for all cmake based projects.
> >  According to the clangd documentation it's currently not possible to
> tell clangd where the compile_commands.json file is. Correct ?
> It is, but you don't want to do that usually, its very cumbersome as
> you need to specify it as a command line arg.

I saw that, and I agree.

One more question: in the Project settings, there is a "Project index". Is 
this an index coming from LSP, or what kind of index is it ?


More information about the KWrite-Devel mailing list