Em sáb., 30 de abr. de 2022 às 13:37, Tom Honermann
<tom_at_[hidden]> escreveu:
> The idea is that, when the compiler is producing a BMI, that it also record the external
> environmental properties that were material in guiding how the MIU was parsed. Perhaps
> it generates a JSON file that reflects what needs to be true for the source file to be parsed
> again in the same way.

I would like to hear from compiler implementers on this topic. But I
suspect that creates a completeness problem that I am not confident
can be solved.

In other words, you need not only a positive indication of the things
that did affect the output bmi, but also a complete mapping of all the
things that would not affect it if they were present.

More importantly, this needs to be communicated in an interoperable
way to allow the build systems to compare them.

> I don't think this approach scales

There's definitely a fine line here. I don't think it'd be as bad as
you're going for.

But you are right that there is an implicit assumption here, which is
that the build systems will need to create a separation of what are
the flags that are meant to use to the translation units on the
target, versus the flags that are meant to use when consuming a
module.

In the case of CMake, for instance (and I'd like to hear from the
CMake folks here), I expect that when creating the target for a
library that imports modules, that imported target will not be
affected by the target that consumes the module. IOW, the module needs
to be parsed with the base toolchain configuration, plus include
directories and compiler definitions defined in the module metadata.
Otherwise you would risk having different parsings of the same module
in the same build, which would very likely result in incoherent builds
in the end.

The consequence of that line of reasoning is that for any target
consuming modules, it would be an error to introduce flags that could
change the format of the format of the bmi at a target level. The good
news is that the build system would be able to test for that by
comparing the baseline hash for the toolchain with the baseline hash
(excluding include directories and compiler definitions) to give the
user a useful output instead of just having the compiler yell that the
bmi is incompatible.

One important note to qualify here is that I am making a distinction
between the *format* of the bmi output and the capability to fully
reproduce a bmi file (which, again, is why I'm making the distinction
from the coherence hashing the compilers are doing).

I guess another way of putting it is that with modules in the picture,
the build system needs to have a clear distinction between what is the
"toolchain configuration" and what is the "target configuration". And
that means that module-aware build systems will have to acknowledge
that making target-specific toolchain configurations will be invalid
when consuming modules, the same way that doing target-specific ABI
choices is invalid when consuming libraries that were produced in a
different way.

daniel