GSoC 2010: Making KDevelop suitable for large C projects

[Milian Wolff]

Nitin Gupta, 27.03.2010:
> Hi,

Hi there!

> For past few months, I have been working on a simple IDE (called KXref)
> based on Sublime UI framework, to allow working with large C based
> projects (Linux kernel in particular): http://code.google.com/p/kxref/
> 
> However, I soon realized that it will be much more useful and productive if
> all this can be developed as plugins for upcoming KDevelop4. My initial
> attempt to get it working for Linux kernel failed badly primarily due to
> lack of cscope, or better GNU global, integration (built-in background
> parser is too slow for such large projects). There are many other factors
> which make it unsuitable for kernel projects (as detailed below).
> 
> Unlike popular belief, an IDE for kernel projects (IMHO) is highly
> desirable. Trying to understand such huge and complex codebases is almost
> impossible otherwise. Plain vim+ctags is often not sufficient.
> 
> I'm planning to submit this as a GSoC proposal. I would be thankful for any
> feedback.

My personal opinion is: One can integrate each and every tool there is for 
KDevelop, but I'd much prefer improving the performance of the build in parser 
instead of using yet another tool for the job... 

I found quite a few places to optimize over the weeks, and I bet there are 
more.

Also support for esoteric C features would be more useful. Afaik there where a 
few bug reports that showed corner cases.

> --------
> Making KDevelop suitable for large C projects
> (Linux kernel in particular)
> 
>  * Integration with GNU global for code cross reference
> (http://www.gnu.org/software/global/):

The DUChain supports cross references, actually it's context browsing is so 
far unrivaled.

>  - Current built-in background parser does not have a persistent storage
> support. This makes it unsuitable for large projects.

We do have persistent storage.

>  - Built-in parser seems to be much slower. Parsing of Linux kernel project
> takes forever to finish.
>  - GNU global advantage over cscope+ctags: Support incremental database
> update, actively maintained with a good roadmap.
> 
>  * Call graphs similar to KScope:
>  - http://kscope.sourceforge.net/callgraph.png
>  - Existing call graph plugin is currently very limited. It currently only
> shows functions called by the function currently under focus.

Again, improve what's there instead of creating yet another plugin...

>  - Currrently, call graph window cannot be “detached” which is almost a
> must for multi-monitor and widescreen setups.

This is a limitation in Sublime which would need to be fixed. Will probably be 
done by Adymo for 4.1 when he drops his custom DockWidgets.

>  * Project templates:
>  - Generic C project template(s)
>  - Linux kernel specific template(s): e.g.: include only x86/x86_64
> architecture files, do not include drivers, etc.

Yeah, that would be really helpful. But again, proper C support might be more 
important, yet I don't know exactly what is not working there.

>  * SCM support:
>  - Git support exists in kdevelop4-extra-plugins but not sure how robust it
> is. For good Linux kernel project support, need to make sure that this
> works well.

This will be done (hopefully) by another GSOC student. I think that alone is 
enough work for a few weeks.

>  - Better file history navigation as supported by p4v for Perforce (as a
> KDevelop plugin): http://www.perforce.com/perforce/products/p4v.html
>
>  * Built-in 'oops' (kernel crash messages) interpreter:
>  - Transform plain oops message into references to functions shown in
> backtrace.
>  - Interpret stack dump into function parameters.

Really good idea, should also be applicable to GDB backtraces.
 
>  * Integration with SystemTap (http://sourceware.org/systemtap/wiki):
>  - Explore existing tap points.
>  - Easily create new one with auto-generated scripts (provide library of
> commonly used scripts).
>  - Visualizers for various kinds of stats exported by SystemTap.

I really think this is far too much for a single GSOC. Also we have the 
problem with lack of mentors, but maybe someone else would be willing to help?

I still would really appreciate at least a few parts of this proposal to be 
put into life. Looking forward to your first patches :)

If you have any questions, go ahead.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100329/2303fcfb/attachment.sig>