Figuring out the CMakeParseJob

[Aleix Pol]

On Wed, Aug 6, 2014 at 9:26 AM, Milian Wolff <mail at milianw.de> 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.
>

> That said, what do you need the backtrace and dependencies for when
> processingthe cmake stuff for language support? You should not need to
> evaluate anything there, hence I don't see the need for proper
> backtraces/dependencies. CMake would just be another scripting language,
> such
> as QML/JS or PHP or Python in that regard. You'd just parse files and offer
> code completion based on built-in cmake stuff which you'll need to get from
> somewhere (cmake documentation?) and whatever you deem useful in a project-
> wide context (and can access through the persistent symbol table then). PHP
> does it like this: Parse a file once, if anything was missing/unknown,
> reschedule once with lower priority.
>
> Bye
>
>
Well, to create a proper duchain we want to be able to see what set() call
is the one that declares the variable. Or well, for macros as well, we
can't have the declaration until it's been processed, and imports in CMake
are specified by the code flow, rather than explicit imports.

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20140806/f99c8811/attachment.html>