Making KDevelop suitable for large C projects
nhaehnle at gmail.com
Mon Mar 29 13:11:02 UTC 2010
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.)
On Sat, Mar 27, 2010 at 6:28 AM, Nitin Gupta <ngupta at vflare.org> wrote:
> 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
> Making KDevelop suitable for large C projects
> (Linux kernel in particular)
> * Integration with GNU global for code cross reference
> - 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
> - 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
> - 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.
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
More information about the KDevelop-devel