[llvm-dev] Adopting a third-party JSON library

James Henderson via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 19 00:50:42 PDT 2020


Two issues that come up with using external libraries just off the top of
my head:

1) Licensing - it's unlikely any of the external libraries use the LLVM
license, so there would potentially need to be legal vetting, both by the
LLVM foundation, and every downstream vendor of LLVM.
2) Updating - how often do we update the external library? What if there's
a bug fix we need to the library, but it isn't in an official release yet?
What if the upstream library decides to drop support for something we still
need/require support for something we don't yet support (e.g. moving to
C++17 before LLVM does)?

Beyond that, I'd want to see evidence that any external library is actually
better than LLVM's homebrew one. For example, you say that we might see
improved performance. This is true, but we might also see WORSE performance
- there needs to be research showing that the performance is better.

On Wed, 19 Aug 2020 at 04:42, David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> LLVM's pretty slim on external dependencies, which makes it a bit
> easier to build, etc - though, admittedly, that's perhaps a nicer
> justification for the sort of "Not invented here" problem that leads
> to the kinds of problems you've mentioned. (at the moment, the only
> library dependency I know of in mainline LLVM is zlib, which is
> optional - other dependencies we carry within the LLVM project, like
> gtest (with all the issues with that - forked codebase, not getting
> new features, etc))
>
> On Tue, Aug 18, 2020 at 8:31 PM Filippo Costa via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > Hi,
> > I'm a new contributor. I'm considering the possibility of adopting a
> third-party JSON library instead of LLVM's homegrown
> `lib/Support/JSON.cpp`. The way I see it, this would bring several
> advantages as well as some downsides:
> >
> >  + Slimmer codebase.
> >  + Benefit from upstream work and active contributions to another
> project.
> >  + Possibly improved performance and API ergonomics.
> >  - Likely compile times regression as many JSON libs are header-only.
> >  - Risk of introducing bugs and breakages across LLVM.
> >
> > As far as I can tell, these are the most popular C++ JSON libs:
> >
> >  * https://github.com/nlohmann/json
> >  * https://github.com/open-source-parsers/jsoncpp
> >  * https://github.com/Tencent/rapidjson
> >
> > I'm trying to understand if this is something I should work on and
> whether or not it would benefit the project.
> >
> > Filippo Costa
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200819/cf40ee3b/attachment.html>


More information about the llvm-dev mailing list