Re: [RFC] duplicate #include check for build system

[Herbert Poetzl <herbert@13thfloor.at>]

On Tue, Feb 21, 2006 at 04:18:57PM -0800, Randy.Dunlap wrote:
> On Wed, 22 Feb 2006, Herbert Poetzl wrote:
> 
> > On Tue, Feb 21, 2006 at 06:52:46PM +0100, Sam Ravnborg wrote:
> > > On Tue, Feb 21, 2006 at 02:29:12AM -0500, Daniel Barkalow wrote:
> > > > On Tue, 21 Feb 2006, Herbert Poetzl wrote:
> > >
> > > > I think the kernel style is to encourage duplicate includes,
> > > > rather than removing them. Removing duplicate includes won't
> > > > remove any dependancies (since the includes that they duplicate
> > > > will remain).
> >
> > > The style as I have understood it is that each .h file in
> > > include/linux/ are supposed to be self-contained. So it includes
> > > what is needs, and the 'what it needs' are kept small.
> > >
> > > Keeping the 'what it needs' part small is a challenge resulting
> > > in smaller .h files. But also a good way to keep related things
> > > together.
> >
> > glad that I stimulated a philosophical discussion
> > about the kernel header files and what they should
> > include or not ...
> >
> > but the idea was more to give the developers an
> > instrument to verify that they are not including
> > stuff several times, and that's actually in .h
> > and .c files, because it seems that often the same
> > header file is included twice in the _same_ file
> >
> > anyway, was this a positive or negative reply?
> 
> Hi Herbert,
> 
> The goal is not to remove the most possible #includes.

which I totally agree with ...

but a) how is that related to _having_ a tool to
check for duplicate includes, and b) how is it
related to removing duplicate includes in general?

let me give a simple example here:

 #include <linux/pm.h>
 #include <linux/sched.h>
 #include <linux/proc_fs.h>
-#include <linux/pm.h>

do you think the second one is really desired?

> E.g., if sched.h already sucks in kernel.h,
> kernel.h still should be #included if the source (.c)
> files uses any APIs or extern data from kernel.h.
> 
> Does that help?

no, sorry, doesn't help here ...

nevertheless thanks,
Herbert

> -- 
> ~Randy