[libc-commits] [libc] [libc] Make two include/llvm-libc-types/ headers more self-contained. (PR #128094)

[Alexey Samsonov via libc-commits]

vonosmas wrote:

> 
> I don't think we should do this, for two reasons.
> 
> 1. Name space: the point of per-type headers is that define only what must be defined to make that type complete.  There may well be places where the type must be available, but the public header isn't supposed to define all the macros that are associated with that type's full API.

So, basically, you're saying the current logic where the termios.h header only works because `llvm-libc-types/struct_termios.h` is included after `llvm-libc-macros/termios-macros.h` (which defines the necessary macros) is "working as intended"? (note that we do have a somewhat reverse case in stdbit.h header, which only works if `llvm-libc-macros/stdbit-macros.h` is included at the very bottom, as the macro there relies on function declarations - see [PR 128101](https://github.com/llvm/llvm-project/pull/128101)).

If that's the case then should we essentially treat everything under both `llvm-libc-types/` and `llvm-libc-macros/` as "textual headers" which are not always expected to work / be analyzed individually? I'm asking this in context of Bazel rules for headers, which we expect to start working on soon.

> 2. Build management: it's currently manually plumbed in CMake what headers rely on which others; but it's not that way in the Fuchsia build, and eventually we should find a way to move the CMake build in the same direction.  That is, pretty much all the dependencies between headers go from a root public `<foo.h>` header directly to a set of implementation headers in `llivm-libc-types` and `llvm-libc-macros`.  The YAML files are the source of truth that produces all the `#include` directives in a fully-generated header (no `.h.def` file, which is where we want to get nearly all of the headers to eventually).  This lets us use automation to manage the build and installation rules for all the headers, rather than manual maintenance of lists of the implementation headers used by the public headers.
> 
> So the contrary change I would recommend here is to remove `termios.h.def` and its `header_template` line in `termios.yaml`.

Acknowledged, so you it looks like you're moving in the direction of `libc/include/fenv.yaml`, which has no `.h.def` file and declares all the macro it needs in YAML itself? That's fine with me, but I'd prefer to make this type of migration in a different PR, this one was aimed at making llvm-libc-types/ headers "work", which may not be a worthy goal at all (see comment above).

https://github.com/llvm/llvm-project/pull/128094