Developing the Linux kernel with KDevelop

[Milian Wolff]

Alexandre Courbot, 24.09.2011:
> 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?

definitely.

> >> 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. See below, patches welcome.

> > 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.

I see. As aleix said, the call to gcc to get the standard include paths is 
probably wrong then as well? Not sure it's an issue though.

> >> 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?

If you maintain it and it's clean code, there is no objection to integrate it 
into kdevelop.

Take a look at e.g. the qmake manager which reuses the core code of the 
generic manager. That makes it quite easy (hopefully) to write new project 
managers and just drop in the custom logic.

> 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.

Convinced, I'll happilly review it.

bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110924/cd410ad3/attachment.sig>