git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	Philippe Blain via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org,
	Philippe Blain <levraiphilippeblain@gmail.com>
Subject: Re: [PATCH] Makefile: add support for generating JSON compilation database
Date: Wed, 2 Sep 2020 01:33:51 +0000	[thread overview]
Message-ID: <20200902013351.GD241078@camp.crustytoothpaste.net> (raw)
In-Reply-To: <20200901073827.GA3967005@coredump.intra.peff.net>

[-- Attachment #1: Type: text/plain, Size: 3162 bytes --]

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.

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  parent reply	other threads:[~2020-09-02  1:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-30 19:28 [PATCH] Makefile: add support for generating JSON compilation database Philippe Blain via GitGitGadget
2020-08-30 22:10 ` brian m. carlson
2020-08-31  2:37   ` Philippe Blain
2020-08-31  4:24   ` Junio C Hamano
2020-09-01  7:38     ` Jeff King
2020-09-01 13:18       ` Philippe Blain
2020-09-02  1:33       ` brian m. carlson [this message]
2020-09-02  8:04         ` Jeff King
2020-08-30 22:17 ` Philippe Blain
2020-09-01 23:09 ` [PATCH v2] " Philippe Blain via GitGitGadget
2020-09-02 17:21   ` Junio C Hamano
2020-09-03 21:17     ` Philippe Blain
2020-09-03 21:31       ` Junio C Hamano
2020-09-03 22:04         ` Philippe Blain
2020-09-03 22:13   ` [PATCH v3] " Philippe Blain via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200902013351.GD241078@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=levraiphilippeblain@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).