Clangd always chooses debug config compile commands with Ninja Multi-Config

[Kaltxi]

When building the project with cmake generator Ninja Multi-Config compile_commands are emitted with commands for all configs for each file (in my case Debug, Release, RelWithDebInfo in that order). Looking at clangd logs it is apparent that clangd always chooses commands for debug config (probably because it is the first one encountered). This leads to various problems, such as loss of includes (qt generated ui_<widget>.h files are not found in the debug autogen folder, as they are in release folder) and might lead to other problems if configs differ significantly.

Can this somehow be solved on the side of clang to determine the correct config to search for?

System information

Output of clangd --version:

clangd version 18.1.3
Features: windows
Platform: x86_64-pc-windows-msvc

Editor/LSP plugin:

• VS Code v1.88.1
• clangd extension v0.1.28

Operating system: Windows 11

[HighCommander4]

To clarify, you have a single compile_commands.json file with multiple entries for the same source file?

[Kaltxi]

Correct, an entry for each config.

[HighCommander4]

Clangs does not currently have any way to control which of multiple entries for a given file in compile_commands.json is selected.

There was one suggestion made in #1288; please feel free to share other ideas there.

My understanding is that users currently handle situations like this by (1) arranging for there to be a compile_commands.json file with only entries for the current configuration, and (2) updating that when switching configurations.

The ways to achieve (1) can range from the build system having a way to directly generate the intended compile_commands.json file, to post-processing a compile_commands.json file with a tool like jq.

For (2), it can be done manually, though I have also come across tools that automate this such as:

• https://github.com/eclipse-cdt-cloud/clangd-contexts/blob/main/examples/clangd-contexts-cli/README.md
• https://github.com/eclipse-cdt-cloud/clangd-contexts/blob/main/examples/clangd-contexts-ext/README.md

[Kaltxi]

@HighCommander4 Thanks for the references! Post-processing seems like an ok compromise to manage the state yourself. A more automated solution I suppose would be to extend compile_commands.json format with config field (like this) and additionally on the side of build system (cmake in this case) to emit a build-time file like current_config.txt with a single entry of the current config corresponding to the last build command which clangd can try to find. This would require changes in both clangd and cmake though...

[HighCommander4]

A more automated solution I suppose would be to extend compile_commands.json format with config field (like this) and additionally on the side of build system (cmake in this case) to emit a build-time file like current_config.txt with a single entry of the current config corresponding to the last build command which clangd can try to find. This would require changes in both clangd and cmake though...

Just to add to this, clangd is not the only tool that consumes compile_commands.json, it's sort of a standard for clang-based tooling in general, as specified at https://clang.llvm.org/docs/JSONCompilationDatabase.html.

So an extension to the compile_commands.json format would probably need to start with an RFC in the LLVM Discourse to update the specification.