Developing the Linux kernel with KDevelop
mail at milianw.de
Wed Sep 21 16:39:31 UTC 2011
Alexandre Courbot, 21.09.2011:
> 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
> a) Isn't the generic project manager independant of make? Why would it
> need to run it in this case?
whops - I didn't read your article in-depth, mostly the error section only and
assumed you used custommake manager.
> 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.
hm true, tracking the info in something like .kdev_defines might work as
well... not sure whether it's fine-grained enough to have that per-directory
> 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.
well, actually if you don't use the custommake manager no wonder it's not
> 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.
/parser/parser.cpp -> you'll need to adapt that to parse it properly
/cppduchain/*builder* -> you'll at least need to change the usebuilder
probably for the ".member =" part.
> 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.
where do you get that number from? ksysguard? if not, please look at it in
> 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
Right, but improving the performance to get it working as it should would be
cool imo. If you have the time (and a 2.6.x kernel machine + intel cpu), try
to run kdev with your kernel project with vtune.
> 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. ;)
as aleix and I said already: We'll be glad to give you a hand. Shout if you
mail at milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the KDevelop-devel