<div dir="ltr"><div>Two issues that come up with using external libraries just off the top of my head:</div><div><br></div><div>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.<br></div><div>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)?</div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 19 Aug 2020 at 04:42, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">LLVM's pretty slim on external dependencies, which makes it a bit<br>
easier to build, etc - though, admittedly, that's perhaps a nicer<br>
justification for the sort of "Not invented here" problem that leads<br>
to the kinds of problems you've mentioned. (at the moment, the only<br>
library dependency I know of in mainline LLVM is zlib, which is<br>
optional - other dependencies we carry within the LLVM project, like<br>
gtest (with all the issues with that - forked codebase, not getting<br>
new features, etc))<br>
<br>
On Tue, Aug 18, 2020 at 8:31 PM Filippo Costa via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi,<br>
> 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:<br>
><br>
>  + Slimmer codebase.<br>
>  + Benefit from upstream work and active contributions to another project.<br>
>  + Possibly improved performance and API ergonomics.<br>
>  - Likely compile times regression as many JSON libs are header-only.<br>
>  - Risk of introducing bugs and breakages across LLVM.<br>
><br>
> As far as I can tell, these are the most popular C++ JSON libs:<br>
><br>
>  * <a href="https://github.com/nlohmann/json" rel="noreferrer" target="_blank">https://github.com/nlohmann/json</a><br>
>  * <a href="https://github.com/open-source-parsers/jsoncpp" rel="noreferrer" target="_blank">https://github.com/open-source-parsers/jsoncpp</a><br>
>  * <a href="https://github.com/Tencent/rapidjson" rel="noreferrer" target="_blank">https://github.com/Tencent/rapidjson</a><br>
><br>
> I'm trying to understand if this is something I should work on and whether or not it would benefit the project.<br>
><br>
> Filippo Costa<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>