> I had to get my project to emit compile_commands.json,
> get clangd, figure out which things about our build
> process clangd was not understanding from
> compile_commands.json and add them in .clangd
That sounds rough. This is anecdotal, but in
my Linux corner of the world, ccls has been
an easier user experience as a C and C++ LSP
since I've never had to resort to messing with
flags in the generated file.
I haven't used clangd myself, though, so I can't say either way, I just know ccls works well.
By convention I tend to have the generated build system in build/ at the top-level of the repo so that the file is at build/compile_commands.json. That, or I'll arrange to have a symlink there pointing to one generated elsewhere.
The nvim snippet I use in my init.lua to setup ccls to work in that scenario is:
vim.lsp.config('ccls', {
init_options = {
compilationDatabaseDirectory = 'build',
},
})
vim.lsp.enable('ccls')
My actual config does also contain a capabilities = ... argument that forwards the default_capabilities() from nvim-cmp, but you get the point. I hope that helps in case you're curious to give neovim another spin.
I haven't used clangd myself, though, so I can't say either way, I just know ccls works well.
By convention I tend to have the generated build system in build/ at the top-level of the repo so that the file is at build/compile_commands.json. That, or I'll arrange to have a symlink there pointing to one generated elsewhere.
The nvim snippet I use in my init.lua to setup ccls to work in that scenario is:
My actual config does also contain a capabilities = ... argument that forwards the default_capabilities() from nvim-cmp, but you get the point. I hope that helps in case you're curious to give neovim another spin.