Re: [PATCH] Makefile: add support for generating JSON compilation database

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sep 2, 2020, 01:33 UTC
Message-ID: <20200902013351.GD241078@camp.crustytoothpaste.net>
In-Reply-To: <20200901073827.GA3967005@coredump.intra.peff.net>

On 2020-09-01 at 07:38:27, Jeff King wrote:

> Likewise. Looking at the output, I'm confused how it would help with
> things like searching and refactoring. It might be nice to spell it out
> for those of us exposed to it for the first time (I tried following the
> links but remained unenlightened).

Traditionally, editors had to learn about every language if they wanted to add special functionality like refactoring (e.g., renaming "struct foo" to "struct bar"), finding all the instances of a type, finding where a type or function was declared, or similar IDE features. When Microsoft developed Visual Studio Code, they decided that they did not want to implement this functionality for every language under the sun, and instead developed the Language Server Protocol[0].

With LSP, each editor needs functionality to speak its portion (either natively, as with VS Code, or with a plugin, such as Vim's ALE) and each language implements a language server to implement its part of the functionality. The protocol is capability based, so implementations can support those features which make sense for their editor or language and omit those which don't. This way, all editors can benefit and language communities can implement one program to provide features, and the problem becomes an O(M + N) problem instead of an O(M * N) problem.

In some languages, like Rust, it's pretty obvious how to compile your project: you use cargo, the built-in build tool. There is also a standard layout to find and enumerate files within a project. However, C is not so standardized, so clangd, which is a clang-based C and C++ LSP implementation, needs help to find out which flags are needed to compile, and therefore find the header files to make sense of parsing the C code and implementing its side of the protocol. That's what this patch implements.

I use Vim and ALE extensively, and it pretty much just works for most languages, including Go and Rust, once you install the LSP server. Git is one of the few projects I work on which is still C and therefore needs help here.

Hopefully this is at least more enlightening about the functionality that clangd provides, why it's interesting, how it works, and why it's valuable.

Show 6 quoted lines

> I'd also be curious to hear what advantages it gives to add a new
> Makefile knob rather than just letting interested parties add -MJ to
> their CFLAGS. Is it just a convenience to create the concatenated form?
> It seems weird that projects would need to do so themselves with sed
> hackery (i.e., I'd expect whatever consumes this json to be able to
> handle multiple files).

I believe clangd does need the concatenated form, and at least the ALE plugin for Vim uses that specific file name to detect whether clangd should be used. The problem is that clangd doesn't know where your source code is actually located and it's very expensive to traverse an entire repository which might contain literally millions of files if you're only really interested in a handful.

[0] https://microsoft.github.io/language-server-protocol/

-- 
brian m. carlson: Houston, Texas, US