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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
