[RFC] Buildtools and Language Support

[Kris Wong]

> -----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.

> 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.

> For cmake I think its even easier, because it doesn't have named
> scope's, its really much closer to a scripting language than qmake.
> 
> > To get code completion for a build system file (assuming it was
> > implemented in the plugin), it would be simpley a matter of letting
> > the language controller know that the langauge support is loaded and
> > having a proper MIME type.
> 
> Oh, thats cool. By the current development in the C++ support 
> I thought
> that each language part would have to do implement quite some extra
> classes to get code-completion working. OTOH I didn't look 
> into that too
> much :)

Allow me to clarify.  By my comment "assuming it was implemented in the
plugin", I was referring to the extra classes required to get code
completion working. =]

Kris Wong