João Távora <joaotavora@gmail.com> writes:

> Hello Gerd. Out of curiosity, and speculation, is your use of 'bear'
> intended to make a compilation database of Emacs sources for use with a LSP
> server?
>
> If so, how is that going? Last time I tried to do that, the server (clangd,
> i think) was still very confused in many files.
>
> João

Hey João, I had issues with Emacs source and clangd, especially with
header files.  The issue is that many of Emacs' C header files are not
"self contained" so they can't be compiled alone.  Also, `bear` will
only generate compile commands for .c files, and clangd uses heuristics
to guess a compile command for nearby .h files.  It does a reasonable
job in some projects, but not Emacs due to the "self contained" issue.
Biggest issue: when editing an .h file clangd won't include <config.h>
for you.

I now do this:

    ./configure <whatever>
    bear --force-wrapper -- make -j$CPUS
    emacs-fixup-compile-commands.py

where emacs-fixup-compile-commands.py is attached.  Bonus to anyone
rewrites it in elisp.  ;-)

The idea is to find the .c file with the most similar name to each .h
file, then form a compile command for the .h by hacking the .c file's
command line, adding:

   -Wno-unused-macros -include config.h

...this way, when clangd "compiles" an Emacs .h file it includes
config.h first (which fixes many issues), and won't complain about
macros going unused in the file.

With this, Emacs + clangd is pretty seamless for me.

P.S. I recently had to start passing "--force-wrapper" to bear.  Some
Emacs builds steps were failing with bear's LD_PRELOAD hack.  Maybe the
Emacs modules stuff?  Or tests?  I didn't look into it, but
"--force-wrapper" fixed it.