Re: linux-next: build failure after merge of the akpm tree

[Andrew Morton]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/