[RFC] Buildtools and Language Support

[Andreas Pakulat]

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.