On Mon, Feb 23, 2026 at 05:32:01PM +0100, Stefano Brivio wrote:
> On Mon, 23 Feb 2026 16:33:32 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Thu, Feb 19, 2026 at 01:44:54PM -0500, Peter Foley wrote:
> > > Support build systems like bazel that check that headers are
> > > self-contained.
> > > 
> > > Signed-off-by: Peter Foley <pefoley@google.com>  
> > 
> > There are kind of two schools of thoughts on headers.  One is that
> > every header should #include anything it relies on.  The other is that
> > headers should #include nothing, and .c files should includde
> > everything they need in the right order.  The advantages of the second
> > approach are that it makes it easier to keep #includes in .c files
> > minimal, and makes circular dependencies more obvious and easier to
> > dientanble.
> > 
> > We've kinda sorta been using approach two in passt, but not entirely,
> > and honestly, it's not really working.
> 
> I would argue it *is* pretty much working, because it builds without
> warnings against glibc and musl, with several versions of gcc and
> Clang, on a large number of distributions and architectures, which is
> what it needs to do.

Ok, let me qualify that.  I mean that I frequently hit minor
irritations related to not-self-contained headers, and I'm not really
feeling the benefits of the approach..  That is to say, I don't feel
like the no-indirect-includes approach is working in the sense of
providing benefits to outweigh going the other direction.

> There are currently two warnings with (unreleased) gcc 16-ish and
> glibc, I still have to post patches for them, but they have nothing to
> do with includes.
> 
> That being said, sure, it's not either approach and admittedly kind of
> arbitrary and rather messy.

Right.

> > So I'm happy to convert to the
> > former approach.  However, if we're adding #includes in the headers so
> > they're self contained, then we should be able to also *remove* a
> > bunch of #includes from .c files (and other .h files) which were
> > previously only there to satisfy the indirect dependencies.
> 
> Just for clarity, while I agree, this patch does *not* magically make
> that Peter's job. :)

Heh, fair enough.

> I'd say that making it build with Bazel is more useful at this stage so
> I would happily accept this patch by itself (I just need to find a
> moment to try out builds on musl and on a couple of distributions,
> first).

Also fair enough.

> The cleanup you propose can also be done independently at a later
> point, also because I'm fairly sure there are a bunch of left-over
> includes (also/mostly from myself) even before this change.
> 
> Note that this kind of cleanup would also take a bit of testing that
> we currently can't automate, for example building against musl on
> Alpine or Void Linux.
> 
> -- 
> Stefano
> 

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson