Location of compile_commands.json

[ghentschke]

IMO the location of the compile_commands.json in a C/C++ project should be part of the toolchain and/or builder. You can tell clangd where to find it by either:

• using a .clangd file in the source folder or
• copy the compile_commands.json into the source tree (after the build).

This will be covered by the current lsp implementation.

Any other opinions?

[jonahgraham]

I am not very fond of the "copy" method. I added to CDT's default CMake project the .clangd method in eclipse-cdt/cdt#290. What is probably needed is something like https://github.com/eclipse-cdt-cloud/clangd-contexts which updates the .clangd file automatically based on which build configuration is selected.

[ddscharfe]

For clangd the compile_commands.json location can also be set via a protocol extension https://clangd.llvm.org/extensions#compilation-commands. According to the documentation it would be also possible to get rid of the compile_commands.json and instead providing it using a language server call.

[ghentschke]

For clangd the compile_commands.json location can also be set via a protocol extension https://clangd.llvm.org/extensions#compilation-commands.

This could be a proper solution when using a LS per project (see #25). The current LSP4E implementation starts a new LS instance for every file which is not part of a project (e.g. external system header). In this case, clangd cannot find a compile_commands.json. The approach above could be a proper solution in this case.

[ddscharfe]

I just saw that there is also a flag to specify the path for the compile_commands.json:

clangd compilation flags options:

--compile-commands-dir=<string>     - Specify a path to look for compile_commands.json. If path is invalid, clangd will look in the current directory and parent paths of each source file

[ghentschke]

I just saw that there is also a flag to specify the path for the compile_commands.json:

Yes, I know. The usage depends on vendor implementation. I think its not very practical, especially when the location can vary depending on e.g. active build configuration.

[ruspl-afed]

especially when the location can vary depending on e.g. active build configuration

in this case I would consider allowing eclipse variables in the path to DB, like ${project_loc}