Developing the Linux kernel with KDevelop

[Alexandre Courbot]

On Fri, Sep 23, 2011 at 6:18 PM, Milian Wolff <mail at milianw.de> wrote:
> Ok, cool. That's even less than what i see personally. I think up to 500MB is
> still OK for larger / many projects in kdevelop.

That would be much better than the "competition" anyway. I don't
really mind about memory usage for big projects as long as reactivity
is here. But of course if I were a core developer of a project I'd
also like it to be as optimized as possible. ;)

>> Good idea - but what do you get more compared to a run with, say, gprof?
>
> Actually useable information and a decent UI. I wouldn't have believed it
> myself but VTune kicks all other profiler's sorry little asses :) Call me a
> fanboy, but I've yet to see anything that comes even near vtune here.

You caught my interest here - I'll try it then. Are you interested in
getting the results?

>> The call to make is hardcoded no matter the kind of project - maybe
>> this could be changed, or even disabled for the generic project
>> manager? There is no reason to think that make is used with it.
>
> There is. The reason is make is quasi-standard. Without doing this, our users
> would have to specify *every* include path themselves which is tedious.

For the custom make manager, that makes perfect sense indeed. But
since it is not a "fits all" solution (kernel comes to mind again,
parsing the output log would not be helpful to figure the include
paths out), I also think one should have the option to disable this.
Make is quasi-standard, but you also still have scons and others.

> Granted, the make-resolver is kinda hackish but so far it works quite nicely.
> I rather wonder why make in dry-mode creates folders. And of course: Try a
> different project manager where you can specify a build folder. "custom make"
> or "custom build system" come to mind.

Unfortunately for kernel hacking these ones are not practical. Not
only you want to use custom include paths (and to remove the system
ones), but you also want to control which sources get included
according to the target architecture and the set of drivers. The only
good way to do this would be to have a dedicated kernel project
manager that infers this from the configuration file, but for now you
have to ressort on the generic project manager and its ability to
filter sources.

>> If you have a suitable project manager, like CMake, this should never
>> be necessary indeed. But for the generic manager, I think not making
>> any assumption and leaving flexibility to the user is key.
>
> Yes, but I think you miss the point somewhat: The generic manager is not
> supposed to be used here imo. The generic manager is more aimed at script
> projects that don't require any kind of building at all, nor have the idea of
> include paths.

Well, maybe I got misleaded by the fact it is called "generic". :p But
what you say tends to confirm that I should go the dedicated project
manager way. Say, one project type for the kernel (including option to
git clone it, and interfaces to submit patches - sounds like a dream
:)), another one for out-of-tree kernel modules. What do you think? I
can work this with an out-of-tree plugin, but would you be willing to
get it into kdevelop's tree once it is stable?

On Fri, Sep 23, 2011 at 10:33 PM, Wolfgang Bangerth
<bangerth at math.tamu.edu> wrote:
>> Changing the project manager won't work. Maybe we could have some
>> per-project setting that lets us disable the make-resolver?
>
> I think that would be useful in any case. We have directories we unit tests
> that have a few thousand .cc files. Furthermore, our Makefiles generate
> dependencies between .cc and .h files by calling a bunch of scripts, which can
> take a while. Letting the make resolver crawl over these directories can take
> 20 minutes on an 8-core machine...

Yup, one should definitely have the option to disable this. Expect a
patch for review soon.

Alex.