GSOC 2012

[Andreas Pakulat]

On 17.02.12 17:28:05, Alexandre Courbot wrote:
> > This is untrue afaik. The maintenance cost of the parser itself is
> > relatively low, it works for most things and hence doesn't need a lot of
> > work unless you want to add new features. The most work is in DUChain
> > and thats the part you cannot replace with CLang.
> 
> The AST builder is still a huge beast and is quite difficult to
> apprehend (like all complex parsers). Also less code is better than
> more code, especially since one can argue CLang's parser is more
> accurate than KDevelop's, no matter how good it is in the first place.

But its sufficient for many people and it is self-contained. That is
also another point, using clang requires installing a separate set of
tools just for parsing, especially for people that use gcc or msvc  this
doesn't make much sense. So until everybody uses clang for building the
C/C++ code there's an extra dependency.

> > This comes up again and again and sure if it has comparable speed to the
> > current parser it would be nice to lay off the burden of the parser. But
> > its a really huge task and needs someone who has in-depth knowledge
> > about the parser and the DUChain already to complete it in a reasonable
> > timeframe.
> 
> You're right in that getting that done during a GSOC is quite
> over-optimistic. On the other hand it could be a nice starting point,
> and the modularity of KDevelop would easily allow for two DUchain
> builders to co-exist.

I don't think this works for the same mimetypes, since the language
plugins are selected based on the mimetype. And there's no point in
adding a second duchainbuilder to the C++ plugin when its going to be
removed later on anyway - lots of changes for no benefit.

Andreas