Subject: bug#70408: 30.0.50; Eglot and Project integration

From: João Távora <[email-masked]>
Date: Sat, 20 Apr 2024 14:10:53 +0100

On Sat, Apr 20, 2024 at 12:28 PM Dmitry Gutov <[email-masked]> wrote:

> > Because of this, C++ projects usually have sth like:
> >
> >    ln -sf build/compile_commands.json compile_commands.json
> >
> > as a build step.
>
> Would you say it's common across most projects? E.g. generated as a
> build step by CMake in out-of-tree comfigurations.
> Or is it something Emacs users tend to add.

Pretty common, yes.  I googled for the ln string:

https://pspdfkit.com/blog/2019/visual-studio-code-for-cpp/  VSCode
https://blog.justforlxz.com/2020/12/23/ccls/  Nvim, I think
https://stackoverflow.com/questions/62461375/clang-using-cmake-to-build-a-compile-commands-json-for-my-project
https://www.reddit.com/r/cmake/comments/u0ztoq/compile_commandsjson_from_cmakelist/
https://clang.llvm.org/docs/HowToSetupToolingForLLVM.html

Then there is this youtube video I happened to catch recently.

https://www.youtube.com/watch?v=nRpvWgymOuc&t=2467s  7:30

But I guess you can make major modes (or user code) or minor-modes
set eglot-server-programs or add methods to
eglot-initialization-options in clever ways to automatically
point clangd to a given compile-commands.json.  And quite likely
you can convince CMake to create it in other places too.  But
I've never needed to, the 'ln' solution is too good.  You can even
commit the symlink.

> What I'm wondering is whether we might be currently disadvantaged
> compared to the users of some other editors, which might have some more
> auto-detection in that area.

Dunno.  At $DAYJOB there are people struggling in VSCode extension
mayhem with faulty static analysis because they have no idea
that the compile_commands.json is a config-time artifact, maybe
the plugin tries to hide that from them?

But I wouldn't be surprised if lsp-mode features this in its
c++-specific file.  Haven't checked.  My policy has always been to keep
language-specific cruft like this out of Eglot, make the common case
easy and allow the fancy case to be coded in .emacs, in major-mode or
libraries.

> I'm open to continuing this discussion somewhere

Don't bother :-) I've given all my feedback on that matter, don't
have time, am happy with my .emacs hacks and so are those Eglot users.