-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't overwrite .clangd file in project root #357
Comments
Hi, sorry for the late answer. |
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 |
I could add a checkbox to disable the generation. The default would be disabled then |
A non-great workaround is to mark |
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.
The text was updated successfully, but these errors were encountered: