On Wed, 24 Oct 2012 12:19:39 -0700 Joe Perches <joe@xxxxxxxxxxx> wrote: > On Tue, 2012-10-23 at 13:02 -0700, Andrew Morton wrote: > > On Tue, 23 Oct 2012 12:51:29 -0700 > > Joe Perches <joe@xxxxxxxxxxx> wrote: > > > > > > btw, what's up with printk_syslog.h? It includes two header files which it > > > > doesn't need but fails to include the two it *does* need: printk_log.h > > > > and types.h. > > > > > > > > > > > > > > printk_syslog.c includes kernel.h (it includes types.h) > > > and printk_log.h. > > > > > > I think printk_syslog.h doesn't need printk_log.h > > > > A general rule is that the header file shouldn't know or care what else > > it's includer has included. Ideally it shouldn't know or care what > > else its includees have included, either. > > > > A fun test would be > > > > for i in *.h > > echo $i > foo.c > > make foo.o > > done > > A whole lot of things in include/ fail this. I bet. > Do you really think that anything using u8/16/32/64 > should include types.h? Well, yes. If someone writes a C file which includes such a header as fisst-included then OK, it will fail and they'll fix things up. But where the problems occur is when that file is *not* the first-included, but they happened to get types.h via another Kconfig-dependent include. Later, the build explodes for someone else. The only reliable way of avoiding this is for each file to include its dependencies. I don't think it's worth going off and trying to "fix" all of this though. Such an exercise has its own risks and this problem just isn't that big - it happens often enough, but it's very easy to fix. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
