Developing the Linux kernel with KDevelop

[Aleix Pol]

On Wed, Sep 21, 2011 at 4:47 PM, Alexandre Courbot <gnurou at gmail.com> wrote:

> Hey,
>
> Thanks for the feedback - glad you found my article heartwarming.
> KDevelop is definitely a project one can be proud about. And yes, I
> think with a few patches here and there it could become a great tool
> for kernel hackers, especially beginner ones. It surely helped me a
> lot already.
>
> I will post my reply to Milian here, where I propose we continue the
> discussion.
>
> a) Isn't the generic project manager independant of make? Why would it
> need to run it in this case?
>
It tries to figure out some include directories by calling a null gcc, maybe
that's the problem?


>
> b) I thought it would make sense to have the automatically included
> files into .kdev_include_paths since it would allow to restrict the
> inclusion to some parts of a project. For the kernel project-wide
> settings are fine, but as far as the generic project manager is
> concerned we may as well try to be, well, generic. :p It seems,
> looking at the code, that these files can already hold other stuff
> (did not figure out what yet though), but if you think project wide
> settings are better, I'm fine with that too.
>
> c) I wonder how far could Makefiles parsing could go for guessing -D
> parameters (especially if some variables need to be expanded). If this
> works, the same thing could be done for -include too. But letting the
> user specify these manually (along with a "guess from Makefile" button
> seems safer.
>

it's what I said on A. I'm not sure what you're going for, though. In an
ideal case, one would never need to add include directories.

>
> d) Yep, although a C++ parser, KDevelop's parser (unsurprisingly) does
> a great job with C - even kernel C. Here I guess being liberal is ok,
> as long as it "just works". I will try to get the C99 initializations
> in after I understand the parsing/DUchain stuff.
>
> I will also try to get the massif metrics you asked (I already use Git
> version). As for memory consumption, parsing the parts of the code I
> have specified in the article + a couple of drivers results in around
> 1GB of memory used, with a good dozen of files opened. By today
> standards, this seems very acceptable and much better than e.g.
> Eclipse anyway. Of course, if you want to parse the whole kernel tree,
> this is another story. The parser would take too much time anyway to
> make this practical, but this is not a real concern. Lookup is just
> fast. Sometimes reverse lookup takes more time than I would expect,
> but this is also the case in Qt projects so nothing like a scaling
> problem.
>
> All in all KDevelop looks pretty fun to work on. In my student days I
> did quite a lot of static code analysis/optimization/specialization,
> so maybe I could also give a hand there, if time allows (which I
> unfortunately doubt). But first I'd like to fix these few things -
> after all, KDevelop is my main work tool, so I'd better shape it right
> for me. ;)
>
> Alex.
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110921/4f92356d/attachment.html>