Developing the Linux kernel with KDevelop

Aleix Pol aleixpol at
Fri Sep 23 12:22:45 UTC 2011

On Fri, Sep 23, 2011 at 11:21 AM, Milian Wolff <mail at> wrote:

> Alexandre Courbot, 23.09.2011:
> > On Thu, Sep 22, 2011 at 3:47 AM, Aleix Pol <aleixpol at> wrote:
> > > It tries to figure out some include directories by calling a null gcc,
> > > maybe that's the problem?
> >
> > That seems to be the case, indeed. In
> > IncludePathResolver::resolveIncludePathInternal(), make is invoked in
> > dry-run mode to try and figure out the include directories. If I
> > prevent this to happen, this directory is not created. The problem
> > seems to be that make is run in the kernel source directory (while it
> > should be run in the build directory), which probably runs some script
> > that prepares the source for building, despite the dry-run mode.
> >
> > 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.
> 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.

Changing the project manager won't work. Maybe we could have some
per-project setting that lets us disable the make-resolver?

> > > it's what I said on A. I'm not sure what you're going for, though. In
> an
> > > ideal case, one would never need to add include directories.
> >
> > 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.
> Bye
> --
> Milian Wolff
> mail at
> --
> KDevelop-devel mailing list
> KDevelop-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the KDevelop-devel mailing list