<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 26, 2019 at 5:39 PM Daniel Mensinger <<a href="mailto:daniel@mensinger-ka.de">daniel@mensinger-ka.de</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">On Sat, 24 Aug 2019 11:38:22 +0200<br>René J. V.  Bertin <<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>> wrote:<br>
<br>> René J.V. Bertin wrote:<br>> <br>> > About that: at first sight a proper implementation would take the existing<br>> > compile_commands.json project management code from the cmake plugin and move<br>> > it to a parent class where it becomes available to other project manager<br>> > plugins too?  <br>> <br>> And another JSON parser than the one from Qt, which fails on larger projects <br>> like digiKam (with a compile_commands.json file that's 87Mb large).<br>> <br>> R.<br>> <br>
<br>Wait... seriously? I am using the QT JSON parser for for the meson plugin (the<br>introspection format is also in JSON (but different from compile_commands.json).<br>
<br>In that case would switching to nlohmann::json be OK? If yes, were should the<br>header be located in KDevelop?<br>
<br></blockquote><div><br></div><div>It's not as easy to integrate Qt code to the Nlohmann::json as it has no knowledge of Qt (and uses the std::string instead), but it's so much easier to handle things, and it can handle gigantic json files.</div><div>it also does not know about QVariants. so there's a little of boilerplate to write if you use it.</div><div>but it's a really serious project and tried to be as fast and efficient as possible.</div><div><br></div><div><a href="https://github.com/nlohmann/json">https://github.com/nlohmann/json</a></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Daniel<br>
</blockquote></div></div>