[llvm-dev] Adding a third-party dependency in clang-tools-extra

[Chandler Carruth via llvm-dev]

On Thu, Oct 19, 2017 at 3:48 AM Sam McCall <sammccall at google.com> wrote:

> clangd communicates with an editor via JSON-RPC. It parses JSON with
> YAMLParser, which is awkward, and generates JSON with printf and friends,
> which is miserable. Much of LLVM does things this way, but clangd does it a
> lot.
>
> I'd like to try replacing this with a JSON library. nlohmann/json[1] seems
> like a reasonable fit: C++11 with exceptions optional, simple build, MIT
> license.
>
> I'd propose vendoring it under
> tools/clang/tools/extra/clangd/nlohmann-json so there's no question of it
> "leaking" into runtimes as described in this thread[2].
> This also means it wouldn't solve llvm's general JSON-parser problem :-)
>
> Any LLVM-level objections or concerns? (Whether that library is the right
> technical choice for clangd can be discussed elsewhere, I think)
> If anyone wants to argue that we *shouldn't* bury it in
> clang/tools/extra/clangd, that's fine too!
>

Generally, I feel like we have continued to find JSON and YAML uses in
LLVM. I think it would be a shame to have more code in that space in the
repository.

But that brings us to another problem: outside of tests, we really
shouldn't add more third-party code with different licenses to LLVM. As a
compiler, LLVM has rather unique licensing requirements. So while this
might be "fine" inside of clangd, if it moves elsewhere (and in many ways
it should!) it would become a problem. Worse, it might be easily missed, or
accidentally end up being used elsewhere.

I would personally be fairly reluctant to take this on unless there is a
pretty huge reason why it is needed. For example, if we had a absolute need
to do proper XML parsing and manipulation, the amount of code required for
that would be untenable without using one of the existing XML libraries.
LLDB for example actually does use an XML library IIRC.

I'm hoping that the problem domain here is substantially simpler and it is
tenable (if never really appealing) to just roll our own....

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171019/8e84a2de/attachment.html>