On Fri, Jun 10, 2022 at 09:33:56 -0400, Daniel Ruoso via SG15 wrote:
> This brings us to another point that has been discussed a few times
> (including an sg15 telecon last year), which is whether or not we
> expect header units to be translated only once, or for it to be
> dependent on the preprocessor arguments of the translation unit
> importing them.
>
> I, personally, am in the camp that header units should be translated
> only once in the project, regardless of the preprocessor arguments

Minor point: per configuration (for single build trees that can handle
building both "release" and "debug" binaries in one build DAG.

I'm of the opinion that this is analogous to "every TU using a header
needs to see a coherent set of declarations" that is already in effect.
Headers configured by defines (Boost PP, C and system headers with their
`_GNU_SOURCE` and friends, etc.) are just not importable IMO.

The alternative is something like (user -> used):

A -> B -> C

If B and C have importable headers, we need to scan C with B's `-D` flag
set and for A's `-D` flag set. Which means we are scanning:

A, B, B_A, C, C_B, C_A

where `X_Y` means "scan X as seen by Y". This only gets worse as the
tree gets deeper if we add a new importable-header-providing dep to C:

A -> B -> C -> D

means scanning:

A, B, B_A, C, C_B, C_A, D, D_C, D_B, D_A

Per-source defines and flags make this even worse because you need to
scan per TU that sees the importable header set.

> used in the translation unit importing it (and this was the consensus
> we had in the sg15 meeting at the time).

IIRC, there was implementation worries about such things.

> It seems the consequence is that the compiler needs to be given not
> only the list of header units and which files they point to for the
> dependency scanning pass, but it also needs the instructions on how to
> preprocess those header units.
>
> I also agree that this seems to be the only reasonable way to implement this.
>
> > But this has potential scalability issues. The most recent
> > thread on this top starts here:
>
> I don't know if I would call it a scalability issue, because it's not
> significantly more expensive than the source inclusion. The compiler

My understanding wasn't so much the performance, but the implementation
complexity.

> just needs to create a new preprocessor state before starting to
> preprocess the imported header. There's no requirement that a full bmi
> be produced at that time, it just needs to know the resulting macros
> after phase 4.

--Ben