Filippo Costa via llvm-dev
2020-Aug-18 14:01 UTC
[llvm-dev] Adopting a third-party JSON library
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
David Blaikie via llvm-dev
2020-Aug-19 03:41 UTC
[llvm-dev] Adopting a third-party JSON library
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
James Henderson via llvm-dev
2020-Aug-19 07:50 UTC
[llvm-dev] Adopting a third-party JSON library
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>
Min-Yih Hsu via llvm-dev
2020-Aug-20 17:20 UTC
[llvm-dev] Adopting a third-party JSON library
In addition to the points made by James and David. I also would like to highlight that since JSON is not in the critical path of LLVM's codebase (i.e. it's mostly used in tools for LLVM's developers), if the current lib/Support/JSON.cpp is good enough in terms of performance and code quality, then I don't think we want to add unnecessary complexities from third-party libraries. Improvements and solutions should always be driven by critical problems, not the other way around. Of course, if you have any concrete material to prove your points (e.g. performance comparison or maintainability study). We would love to see :-) Thank you -Min 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 >-- Min-Yih Hsu Ph.D Student in ICS Department, University of California, Irvine (UCI). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/d96cace7/attachment.html>
Michael Kruse via llvm-dev
2020-Aug-20 17:38 UTC
[llvm-dev] Adopting a third-party JSON library
lib/Support/JSON.cpp has been written because the community did not want to add an external dependency or copy a 3rd party JSON library. See http://lists.llvm.org/pipermail/llvm-dev/2017-October/118583.html for th discussion. Since JSON.cpp now is integrated in the codebase, there now is even less reason to switch to a 3rd party implementation. Michael Am Di., 18. Aug. 2020 um 22:31 Uhr schrieb Filippo Costa via llvm-dev < llvm-dev at lists.llvm.org>:> 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/6c2060ae/attachment.html>
Seemingly Similar Threads
- Adding a third-party dependency in clang-tools-extra
- Adding a third-party dependency in clang-tools-extra
- RFC: Adding a JSON library to LLVM Support
- GSoC Interested Student:Encode Analysis results in MachineInstr IR, Slimmer project
- c++ Development question