.clangd path incorrectly prefixed with project_name

[alexkaratarakis]

Given 2 CMake build configurations, let's say Debug and Release, when switching between them, the extension is modifying the .clangd file with a new path to account for the build configuration change.

However, it seems it defines the path prefixed with the project name like so:

CompileFlags: {CompilationDatabase: /my_project_name/_build/Debug}

(including the root /), but the correct path should be:

CompileFlags: {CompilationDatabase: _build/Debug}

As such, after switching configurations clangd doesn't work correctly. If I manually modify the path in .clangd to trim the /my_project_name prefix and restart Eclipse, clangd is restored to working order again.

Is this a bug or is there a misconfiguration on my part?

[ghentschke]

Is this a bug or is there a misconfiguration on my part?

I assume that's a bug. Which OS are you using?

[ghentschke]

Which C/C++ project type are you using in CDT? Normally you cannot switch build configuration in a CDT Cmake project.

[alexkaratarakis]

I assume that's a bug. Which OS are you using?

Ubuntu 24.04, more specifically:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 24.04.1 LTS
Release:	24.04
Codename:	noble

Which C/C++ project type are you using in CDT? Normally you cannot switch build configuration in a CDT Cmake project.

Using Cmake4eclipse. Was pretty sure that was the recommended one here, but reviewing the README, that is not the case. I will try setting up a CDT Cmake project.

[alexkaratarakis]

Indeed, the builtin CDT Cmake project doesn't have multiple build configurations.

I wasn't able to find a way to trigger the .clangd generation in the builtin Cmake project type to test, is there a way to do that? Or is this behavior specific to cmake4eclipse?

[ghentschke]

I wasn't able to find a way to trigger the .clangd generation in the builtin Cmake project type to test

When you create new CMake project in CDT (Empty project or Hello World), there should be .clangd file in the project root folder, containing the default path to the compile_commands.json file:

CompileFlags: {CompilationDatabase: build\default}`

As there are no different build configurations for a CMake project, the path would not be changed automatically.

Or is this behavior specific to cmake4eclipse?

Which behavior do you mean? The automatic setting of the CompilationDatabase path in the .clangd file to the folder containing the compile_commands.json ?

I hope this will help you

[alexkaratarakis]

Which behavior do you mean? The automatic setting of the CompilationDatabase path in the .clangd file to the folder containing the compile_commands.json ?

Yeah, that's the behavior I mean, but it is indeed a concern specific to using cmake4eclipse.
Is cmake4eclipse in scope or are there perhaps plans to put it in scope in the future?

There are a couple of issues like this thread and this other thread, but otherwise the lsp seems to be working well with cmake4eclipse. But understandable if it is not in scope.

[ghentschke]

Is cmake4eclipse in scope or are there perhaps plans to put it in scope in the future?

No, I think not really. With an LSP (LanguageServerProtocol) based editor there is IMO no need to use cmake4eclipse any more. Because when I am right, cmake4eclipse is an adapter to provide (mainly) information to the CDT indexer used by editor-, outline-,call/type-hierarchy-view,... With the new editor these information are provided by the Language Server (clangd).
IMO the general cmake support in CDT could be improved.

[ghentschke]

There are a couple of issues like this thread and #357,

yes, we've still some work to do.

[alexkaratarakis]

Sounds good, will close this then.

[rc-jpbarbosa]

We ran into this issue using CDT-LSP alongside cmake4eclipse too. Our workaround was to pass the compilation database path to the CLI, like --compile-commands-dir=./build. Seems to override the incorrect config value. This can be set in the project settings Editor (LSP) > clangd > Additional

[ghentschke]

Our workaround was to pass the compilation database path to the CLI, like --compile-commands-dir=./build

The disadvantage here is that the --compile-commands-dir accepts no source relative path. Therefor it cannot be used in a workspace with several projects and multiple compile_commands.json files.