You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a follow-up to issue #227, since the problem now arises again (since CDT LSP vers. 3.0 or 3.1).
Issue description
We have the following set-up: There is one common root folder that contains numerous sub-directories with C/C++ Eclipse projects. The root folder contains the compile_commands.json (the compilation database) for all the projects. CDT LSP creates a .clangd file with wrong settings for each of these C/C++ projects and corrupts our clangd configuration.
In CDT LSP versions prior to vers. 3 this issue was already fixed. CDT LSP did find the compile_commands.json in one of a project's parent folder and used that. But now, the issue appears again.
It would be great if the issue could fixed without forcing the users to implement Eclipse plug-ins for customizing CDT LSP, since our set-up (root directory with a compile_commands.json and multiple projects in sub-directories using the same compile_commands.json) seems to be quite common. In addition, in order to avoid regressions in upcoming CDT LSP versions, automated tests should ensure that no .clangd file is created in such cases.
...folder/s. If a .clangd file exists in the given project, it will be
updated. Otherwise parent folders until root will be searched for a
.clangd file. Its implemented in the
DefaultClangdCompilationDatabaseProvider to allow vendors to overwrite
this behavior if needed.
This is a follow-up to issue #227, since the problem now arises again (since CDT LSP vers. 3.0 or 3.1).
Issue description
We have the following set-up: There is one common root folder that contains numerous sub-directories with C/C++ Eclipse projects. The root folder contains the
compile_commands.json
(the compilation database) for all the projects. CDT LSP creates a.clangd
file with wrong settings for each of these C/C++ projects and corrupts our clangd configuration.In CDT LSP versions prior to vers. 3 this issue was already fixed. CDT LSP did find the
compile_commands.json
in one of a project's parent folder and used that. But now, the issue appears again.It would be great if the issue could fixed without forcing the users to implement Eclipse plug-ins for customizing CDT LSP, since our set-up (root directory with a
compile_commands.json
and multiple projects in sub-directories using the samecompile_commands.json
) seems to be quite common. In addition, in order to avoid regressions in upcoming CDT LSP versions, automated tests should ensure that no.clangd
file is created in such cases.Additional, likely related issues:
#252 #436
The text was updated successfully, but these errors were encountered: