<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 6, 2014 at 10:30 AM, Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On Wednesday 06 August 2014 09:26:44 Milian Wolff wrote:<br>
> On Wednesday 06 August 2014 03:58:38 Aleix Pol wrote:<br>
> > Hi,<br>
> > Now this is the e-mail where I'm a newbie after working on KDevelop for 7<br>
> > years :D.<br>
> ><br>
> > As you'll have seen, I've been changing things in the cmake, one of the<br>
> > things to have changed is how we populate the DUChain, we will use parse<br>
> > jobs now.<br>
> ><br>
> > Now I think we'll need to treat it a bit specially, given that in cmake we<br>
> > need to have the scripts processed in a specific order so that we know<br>
> > where things actually come from.<br>
> ><br>
> > Now I would like some feedback from the people who have been working on<br>
> > other language supports to give me a hand figure this out, so I can start<br>
> > pushing this with confidence.<br>
> ><br>
> > Let's put it in perspective, we need to be able to include the backtrace<br>
> > of<br>
> > the file every time we parse a file, so if we're doing:<br>
> > - src/CMakeLists.txt: we will need /CMakeLists.txt<br>
> > - cmake/FindCocoloco.cmake: we will need src/CMakeLists.txt, which in turn<br>
> > needs CMakeLists.txt<br>
> ><br>
> > Also we need to be able to wait the processing of the files until the<br>
> > dependencies are not ready.<br>
><br>
> Hey Aleix,<br>
><br>
> great work. Good to see this happening! I wonder though: From the commit<br>
> message it reads as if "only" defines and include paths are read directly<br>
> from CMake, nothing else. What else would there be? I.e. what exactly is it<br>
> that you need from CMake but don't get, yet? As I mentioned before, once we<br>
> have a properly documented spec of whats required on our side, we can<br>
> approach the CMake guys and ask for help from their side.<br>
<br>
</div></div>Also, shouldn't this work go on in a separate branch, and not in frameworks<br>
directly? I'd say we should revert it in frameworks until it's ready, no?<br>
<br>
Note e.g.: <a href="http://build.kde.org/job/kdevelop_frameworks_qt5/67/console" target="_blank">http://build.kde.org/job/kdevelop_frameworks_qt5/67/console</a> In Qt5,<br>
I'd say we should use QJsonDocument & friends, which would remove the<br>
dependency on QJSON.<br>
<div class=""><br>
Bye<br></div></blockquote><div><br></div><div>Yes, QJSON is not needed anymore. <br></div></div><br></div></div>