Currently, KDevelop is within inches of properly parsing the kernel! However, we are lacking some very key features necessary for this. Most of these are options we pass gcc at the command line for which there is no equivalent (yet) in KDevelop's awesome code parser. Minimum Requirements ==================== 1. Ability to define macros manually. Some headers are used in both kernel- & user-land. When an object file is built for use in the kernel, the main Makefile's KBUILD_CPPFLAGS=-D__KERNEL__ is used. We need a mechanism to set pre-processor variables such as this manually. 2. Ability to include files automatically. This is covered in bug #315705. Again, at the gcc command line, the kernel build system automatically includes include/generated/autoconf.h for the build of each kernel-space (KBUILD) object file. 3. Ability to exclude system include paths. It's so irritating to me when I'm working on my usb driver and I hover over something from include/linux/usb.h and it has parsed information to /usr/include/linux/usb.h! argh! Things that will help ================= 4. Defer FAM hooks If I make the mistake of building the kernel while KDevelop is open, my system practically grinds to a halt. This all appears to be due to KDevelop immediately responding to file alteration monitor hooks excessively when many files are being changed very quickly. It would seem to me to make more sense to only process FAM notifications a few times every second (and accumulate the list of files changed), but perhaps I just need to properly tell KDevelop to ignore all of the .o, .cmd.c, etc files? See Also: * A nice article entitled "Hacking the Linux kernel with KDevelop" -- http://www.gnurou.org/code/kdevelop-kernel Should I open separate bugs for items 1 and 3 and mark this bug as dependent upon them?
Oh yes, and as to item #4, this happens also with out-of-tree module projects. A work-around is not to use the custom Makefile project template!! As it turns out, this is what prevents me from telling KDevelop to ignore the files that are going to be created and deleted at a rate of 100+ times per second (if the CPU wasn't being burried by KDevelop anyway).
Hi Daniel, It would definitely help having separate issues, so that we can tackle them separately. Thanks for the interest, and I know it's not what you'd like to hear, but patches welcome. ^^
(In reply to comment #2) > Thanks for the interest, and I know it's not what you'd like to hear, but > patches welcome. ^^ Hey! That's my line! > It would definitely help having separate issues, so that we can tackle them > separately. Oh yes, and I should open those. Well give me a few days to forget abo... I mean finish up some stuff and I'll open some bug reports for the items where there aren't already issues and maybe actually look at the KDevelop code to see if I can come up with anything. The parsing of KDevelop is really nice when it works and I finally came up with some hack-arounds to get it to work (putting silly stuff in my sources).
I just opened bug 329788 for point 1.