Messages in this thread | | | Date | Tue, 21 Feb 2006 16:18:57 -0800 (PST) | From | "Randy.Dunlap" <> | Subject | Re: [RFC] duplicate #include check for build system |
| |
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.
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?
-- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |