[llvm-dev] Adopting a third-party JSON library
Min-Yih Hsu via llvm-dev
llvm-dev at lists.llvm.org
Thu Aug 20 10:20:49 PDT 2020
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 :-)
On Tue, Aug 18, 2020 at 8:31 PM Filippo Costa via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
Ph.D Student in ICS Department, University of California, Irvine (UCI).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev