[PATCH] D145228: [clangd] Add clangd headers to install targets

Sam McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Mar 6 02:23:14 PST 2023


sammccall added a comment.

In D145228#4170826 <https://reviews.llvm.org/D145228#4170826>, @DmitryPolukhin wrote:

> In D145228#4170792 <https://reviews.llvm.org/D145228#4170792>, @sammccall wrote:
>
>>> The install target for clang distributes the clangd static libs
>>
>> I don't think this was ever intended, looks like an accidental side-effect of using LLVM's many cmake macros.
>> Can we fix this instead?
>
> Why not allow people building custom clangd outside of LLVM repo?

Clangd isn't designed as a collection of libraries.
In a separate build system where it was (accidentally) easy to consume these, we've had issues with people using things like ParsedAST as a general interface to clang.
There *was* a goal to have it possible to essentially embed the whole thing into a different system. That's pretty involved and AFAIK has one user today, as such integrating with the build system seems like a better tradeoff than relying on all clang users installing this library + headers, dealing with version skew between the headers and the consuming application, etc.

> There was exactly the same issue with clang-tidy (see D73236 <https://reviews.llvm.org/D73236>)

Sure, if clang-tidy maintainers are happy to support clang-tidy as engine + library checks for running against ASTs, in addition to the clang-tidy tool per se, I guess that makes sense. I don't think it follows that it makes sense for clangd.

> In comparison with headers, libraries takes much more space

As I said, including the libraries looks like an oversight, the intent was to distribute clangd as a binary only.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145228/new/

https://reviews.llvm.org/D145228



More information about the cfe-commits mailing list