> 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.