Multiple compile_commands.json for every project build configuration

[almi33]

Project might have several build configurations. Is there a way to specify the path to compile_commands.json for each build configuration?

[ghentschke]

Is there a way to specify the path to compile_commands.json for each build

It depends on the project you are using. When you have several build configs, I assume that's a CDT managed build project? The compile_commands.json from the active build configuration is used. If you want to specify a specific compile_commands.json you've to deactivate the automatic detection:

... and set the path in the .clangd file manually

[almi33]

It is not a CDT managed build, but a project with manually written CMakeLists files.
So, you suggest to change .clangd file manually every time I switch from one build configuration to another?

[ghentschke]

It is not a CDT managed build, but a project with manually written CMakeLists files.

Can you please provide the project natures:

Vanilla CDT has these project type:

AFAIK CMake projects do not have multiple build configurations except you use cmake4eclipse. They have the launch modes Debug and Run which builds the project either with debug information or not.

So, you suggest to change .clangd file manually every time I switch from one build configuration to another?

No, but there was might be a little misunderstanding from my side. I am trying to understand your project setup.
What CDT-LSP does, if the checkbox Set compilation database path in .clangd file has been enabled: It tries to update the path to the compile_commands.json (which is generated either by CMake for CMake projects or by CDT if it's a managed build project using Make files) in the .clangd file depending on the active build configuration for managed build projects or by the last build in CMake projects (Run or Debug):

Other project types are not supported.

[almi33]

Here are project natures:

Other project types are not supported.

Please read Where has the "C projects" wizard gone ?
There @lesnake describes what I believe a bug and I give a workaround because I've experienced the same issue some time ago.

[almi33]

Sorry, I missed some of your comments on first read. So here is continuation.

I assume you've already read a discussion referenced in a previous comment.
Project is not a managed one. Earlier it was called "Makefile project" and for this kind of projects CDT did not provide service of generating Makefile and other things managed project does. Makefile should have been written manually and correct settings should've been applied to get information about includes and macros. I'm using "Makefile project", simply with CMake instead of Make.
What can stop me from making project with build system based on CMake and having multiple build configuration?
Build configuration not necessarily Debug and Release, it might be anything. The example that I've experienced personally is - different pin compatible microcontrollers on the same board. In this case two applications need to be built and build configurations to achieve this goal are MCUA and MCUB but not Debug and Release.
Perhaps it makes sense for CDT-LSP to update path in .clangd but what if the path to compile_commands.json is not "build" folder?

[almi33]

And to continue previous comment: what if mentioned earlier build configurations MCUA and MCUB have different sets of compile commands, either completely different or partially?

[ghentschke]

what if mentioned earlier build configurations MCUA and MCUB have different sets of compile commands, either completely different or partially?

Clangd captures the compile commands from the compile_commands.json file. That's why CDT-LSP add it's containing folder directory path in the .clangd file. The compile_commands.json will be generated for CMake projects by CMake or for Managed Build Projects (a.k.a. MBS) by CDT.

I think the generation does not work properly for Make projects.

When you have multiple build configurations in MBS, then the path to the build folder of the active configuration will be written into the .clangd file. So the compile commands from the active build config are used by clangd and the editor.

[ghentschke]

What can stop me from making project with build system based on CMake and having multiple build configuration?
Build configuration not necessarily Debug and Release, it might be anything

You can create your own build configurations in a MBS project. I think MBS is dedicated for embedded C/C++ development.

[almi33]

Can you please explain what MBS stands for? I failed to find it?

[ghentschke]

Sorry, MBS is Managed Build System:

[ghentschke]

Please notice that a compile_commands.json in a Makefile project generated like this is not created automatically.
You have to enable it (workspace wide) in the Preferences -> C/C++ -> Build --> JSON Compilation Database Generator --> Generate compile_commands.json file

And the Generate Makefiles automatically option must be set as well:

Then the compile_commands.json will be generated and the path will be set in the .clangd file after a projects build:

[almi33]

Well, the need to select C/C++ -> Build --> JSON Compilation Database Generator --> Generate compile_commands.json is crucial in this case - I haven't seen it in help, but maybe because I wasn't careful enough.
Selecting Generate Makefiles automatically essentially turns Makefile project into managed one. Moreover selecting Builder type as Internal builder instead of External builder

allows to build project without generation of Makefiles. Neither of these is so interesting at least because Makefile is written manually. Anyway I've tried both and can tell that yes both are working almost as expected with compile_commands.json generation and update of .clangd file for both settings being applied globally at Preferences level or locally at Project properties level. Exceptions:

1. For cross compiler I've set arm-none-eabi- prefix in project properties

   

   What I noticed is that every "command" field in every entry of compile_commands.json file starts from arm-none-eabi- but not from arm-none-eabi-gcc:

   

   Compiler name that is configured here:

   

   is missing.

2. Path to clangd itself shall be specified globally on Preferences level. Settings in Project properties ignored. It has been discussed already and given here only for completeness.

3. Ctrl+Left click over #include doesn't navigate to header, it even doesn't show it as a hyperlink when Ctrl is pressed and mouse is hovering over. All includes and symbols seem being resolved - no warning are shown. And project compiles and links without warnings or errors.

4. Unknown argument error is reported

   

   Could it be a good idea to introduce "Suppress unknown argument error" setting so it is not shown every time some file is open?

Well, now back to topic.
Makefile projects, I mean MBS projects that neither use Generate Makefiles automatically while External builder is selected nor select Internal builder are very useful. They are useful because besides of Make they allow to use virtually any build tool - Make (already mentioned), CMake (not a build tool but still), Meson (like CMake as I understand), whatever-can-be-run-from-command-line.
To achieve this I create a set of custom Build targets (Right click on project > Build targets > Create), for example here are targets for project that uses Make:

Build target all looks like:

Instead of make in Build command it is possible to use any tool that can be run from command line - for example cmake. And here is the example of custom targets for project that uses CMake:

Where target generate looks like:

Here the first option is for generation of compile_commands.json, thus it is not necessary to select Generate compile_commands.json in settings.
Other options contain references to ${CL_SOMETHING}. These are just Eclipse variables. They are defined in project properties C/C++ Build > Build Variables:

Every Buld configuration in the project can have its own set. Yes here it is only one configuration, but multiple are easily possible. Moreover it is possible to have build configurations that utilize different build tools - some might use Make while others might use CMake, of course different custom Build targets need to be created.

I assume that .clangd file doesn't fit and its update need to be disabled as discussed earlier - correct me if it is wrong.
So questions:

1. Can I refer to Eclipse variables from _Additional_field of clangd settings to pass a path to compile_commands.json?

   

2. Would it be a good idea to make selection of Enable project-specific settings possible for every Build configuration, both for clangd and Editor (LSP)?

[ghentschke]

Thanks for the detailed info. I didn't know these settings. To your questions:

Can I refer to Eclipse variables from Additional field of clangd settings to pass a path to compile_commands.json?

No. The additonal field is only for clangd command line arguments.

Would it be a good idea to make selection of Enable project-specific settings possible for every Build configuration, both for clangd and Editor (LSP)?

No, I don't think so. clangd uses curently only a single compile_commands.json. You have to select one form your build configs.
Currently we support only a clangd LS per workspace. I'll disable/hide the clangd settings on project level to prevent a malformed configuration as you had.

clangd searches for a .clangd or compile_commands.json file in the source folder and its parents. That's why we palced the .clangd file in the project root directory.

If you find a way to place the generated compile_commands.json you want near your code it shall work without a .clangd file either.

[ghentschke]

For cross compiler I've set arm-none-eabi- prefix in project properties

This is a known CDT issue. There is still a PR open here: eclipse-cdt/cdt#1138