Figuring out the CMakeParseJob

[Aleix Pol]

On Wed, Aug 6, 2014 at 10:30 AM, Milian Wolff <mail at milianw.de> wrote:

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

Yes, QJSON is not needed anymore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20140806/ab26c9fe/attachment.html>