Making KDevelop suitable for large C projects

[Nicolai Haehnle]

Replying as a user, not a developer, of KDevelop.

My biggest question is: How do you plan to deal with mixed C/C++
codebases? If the C support feels alien and disconnected to the
support of C++, that would be very unfortunate. I'm already using
KDevelop for moderately sized C/C++ codebases and am fairly happy with
it (except I agree that the performance of the parser could be
better). However, if any change would make KDevelop behave
inconsistently depending on whether I'm in a C or a C++ source file,
I'd be rather unhappy about that.

Maybe it would be better to say "Making KDevelop suitable for large
projects", and then take the C-only Linux kernel as a special
subproblem of that. (Yes, C and C++ are different languages, but they
are still similar enough and, importantly, can share structures and
functions that should be cross-referenced correctly.)

cu,
Nicolai

On Sat, Mar 27, 2010 at 6:28 AM, Nitin Gupta <ngupta at vflare.org> wrote:
> Hi,
>
> 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.
>
> --------
> 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/):
>  - Current built-in background parser does not have a persistent storage
> support. This makes it unsuitable for large projects.
>  - 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.
>  - Currrently, call graph window cannot be “detached” which is almost a must
> for multi-monitor and widescreen setups.
>
>  * 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.
>
>  * 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.
>  - 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.
>
>  * 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.
>
> Thanks,
> Nitin
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>