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

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Tue Aug 18 20:41:53 PDT 2020

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

More information about the llvm-dev mailing list