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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 24 Feb 2006 08:23:23 +0100 (MET) Jan Engelhardt 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.
> >
> How far does this go? Consider the following hypothetical case:
> 
> ---dcache.h---
> struct dentry {
>    ...
> };
> ---fs.h---
> #include "dcache.h"
> struct inode {
>     struct dentry *de;
> };
> 
> Since only a pointer to struct dentry is involved, I would compress it to:
> 
> ---fs.h---
> struct dentry;
> struct inode {
>     struct dentry *de;
> };
> 
> The fs.h file still "compiles" (gcc -xc fs.h), and there is one file less 
> to be read. And since dcache.h in this case here should anyway be included 
> in the .c file if *DE is dereferenced, I do not see a problem with this.
> Objections?

Nope, your method is good & correct AFAIAC.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux