Re: [PATCH] Add missing includes to headers

On Mon, Feb 23, 2026 at 05:32:01PM +0100, Stefano Brivio wrote:

On Mon, 23 Feb 2026 16:33:32 +1100 David Gibson 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

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