Developing the Linux kernel with KDevelop

[Alexandre Courbot]

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?

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.

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.