Open rc-jpbarbosa opened 4 months ago
Hi, sorry for the late answer.
you can disable the .clangd creation by implementing this interface as an OSGi component with a servcie ranking > 0. This will override the default implementaion in org.eclipse.cdt.lsp.clangd.internal.config.DefaultClangdCompilationDatabaseSettings
. For reference see the default implementation here.
I was hoping this could be implemented as a feature of the plugin itself, such as with a checkbox in the project settings in Eclipse. Many projects contain a .clangd
file in their root directories, checked into their version control, and the LSP plugin overwriting it would be seen as undesirable.
Many projects contain a .clangd file in their root directories, checked into their version control, and the LSP plugin overwriting it would be seen as undesirable.
I could add a checkbox to disable the generation. The default would be disabled then
A non-great workaround is to mark .clangd
as read-only.
As a user I'd like the option to maintain my own
.clangd
configuration file (in the project root) without the CDT-LSP plugin overwriting it.Most importantly, when used with the cmake4eclipse plugin, the
CompilationDatabase
is incorrectly set to the path specified inC/C++ Build > Build location > Build directory
instead of the actual build path specified inC/C++ Build > Cmake4eclipse > Build output location > Folder
. This makes the plugin unusable in our project because the resultingCompilationDatabase
path does not exist.(Note: modifying
C/C++ Build > Build location > Build directory
to matchC/C++ Build > Cmake4eclipse > Build output location > Folder
is not possible while theGenerate Makefiles automatically
option is checked, as it is in our project)We already have steps in our CMake configuration for copying our
compile_commands.json
to an appropriate directory where clangd can find it, so we don't need the plugin to specifyCompilationDatabase
at all. We do this in CMake so that clangd will work in our project regardless of the build folder name or IDE being used.Additionally, the plugin will modify the formatting and strip out useful comments within the
.clangd
file, meaning we have to take additional measures to ensure these unwanted changes aren't committed to our repository.I've read through the discussion in the similar issue #227 and, unless I'm misunderstanding the resolution, forking and modifying the plugin ourselves is not a suitable option for our team.