On 13.07.07 09:35:26, Kris Wong wrote:
> > -----Original Message-----
> > From: Andreas Pakulat
> >
> > >
> > > My main concern would be whether the language
constructs for each of
> > > these build systems could easily represented
by the
> > duchain, or whether
> > > there would have to be a lot of work done for
this to
> > function properly.
> >
> > I have to admit that I don't have enough knowledge
about duchain to
> > comment on that. So lets see what constructs qmake
haa:
> > qmake has variable-assignment, function calls
which create a
> > new context
> > (duchain-context) and named contexts. there are
some built-in
> > functions
> > for which there's no declaration, but any
user-supplied function has a
> > proper declaration (via a function-call+context
with the
> > implementation).
>
> That's one large issue with build systems (especially
qmake). There is
> a tone of built-in functions and variables for which
there are no
> delcaration. For proper language support these things
would have to be
> represented in the duchain. Which likely means having
to insert them
> all manually. Which then means keeping all this
information up to date
> as the build system changes.
QMake isn't likely to change that much during the Qt4
lifetime (at least
that didn't happen during Qt3 AFAIK). I'm not sure yet how
to deal with
qt3 specialties, like functions that didn't exist in qt3,
but I
definetly will not build 2 parsers or 2 duchains.
> > So except the named-scope I think those things can
be represented by
> > classes from the duchain. Am I wrong?
>
> One issue that comes to mind is the whole idea of
sub-directories for
> build systems. i.e., One directory simply has a
project file that
> informs the build system to look into these other
directories. DUChain
> is currently setup for handling c++ source files, which
are all
> independet translation units. There is no relationship
between them,
> persay, so this type of thing cannot be represented by
the current
> DUChain (unless sub-directories could be thought of as
child contexts of
> the build system file that "included" them...
maybe/maybe not?).
> Something to think about.
Hmm, right. Well, in KDev3 I did more or less that, for each
.pro file I
wrapped the AST into a Scope instance (which had all the API
fuer
adding/removing variables and subscopes) and a .pro file in
a
subdirectory is just "another" child Scope of this
Scope. Except that
the child scope doesn't inherit anything from its parent
scope, thats
only working with include() and scope/function-scopes.
Andreas
--
There is a 20% chance of tomorrow.
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel
|