Making KDevelop suitable for large C projects

[Nitin Gupta]

On 03/29/2010 06:41 PM, Nicolai Haehnle wrote:
> 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.
>

My intent is not to change KDevelop behavior based on C or C++ in
any way. Instead, I intend to implement set of plugins or maybe some
enhancements to core that make it suitable for handling large C projects.
These plugins will simply be less (or not) applicable if the project is
largely based on C++ or other languages instead.
 
> 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.)

The changes I intend to make are specifically targeted at making it suitable
for large C projects. Many of those changes are probably applicable for other
types of large projects too but still I don't think intended additions/changes
justify giving the application such a generic title.


Thanks for your comments,
Nitin


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