eclipse-cdt / cdt-lsp

Eclipse CDT™ LSP Extensions for CDT
Eclipse Public License 2.0
26 stars 11 forks source link

`.clangd` path incorrectly prefixed with project_name #373

Open alexkaratarakis opened 3 weeks ago

alexkaratarakis commented 3 weeks ago

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 commented 3 weeks ago

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

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

ghentschke commented 3 weeks ago

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

alexkaratarakis commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 1 week ago

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 commented 5 days ago

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 commented 5 days ago

There are a couple of issues like this thread and https://github.com/eclipse-cdt/cdt-lsp/issues/357,

yes, we've still some work to do.