On Fri, Apr 29, 2022, 17:13 Tom Honermann <tom@honermann.net> wrote:I'm not sure how to interpret your response here.I think we're not talking about the same thing. What you're describing is what in the paper I described as the "hashing" mechanism that compilers are implementing. They do what you're describing, however you would end up with a unique hash per module, meaning that we would have to fully preprocess the module interface unit prior to deciding if that binary interface file is usable in this context or not.
No, that is not what I'm suggesting. Let me try again.
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. As indicated, this would include predefined macros (both those predefined by the compiler, possibly dependent on compiler options, plus those specified on the command line, but not macros defined or undefined in the MIU). This would be a minimal subset of all external factors (e.g., macro FOO must be defined, macro BAR must not be defined, macro BAZ must have a value of 3, etc...).
With that minimal subset in mind, a build system can compare it
to the "baseline" configuration to see if it satisfies the minimal
subset. If it does, then the BMI can be reused and if it does not,
then a new BMI is needed. As desired, no preprocessing or other
analysis of the MIU would be required by the build system.
The goal of this paper is to allow this step to be skipped, by having a "baseline" configuration for the compiler as it is being used in a given target, at which point any bmi matching that identifier can be presumed to be compatible without ever having to read the module interface file. That identifier would then be communicated in the module metadata as it was distributed with the library.
I don't think this approach scales. For example:
This means the build system would be able to even short-circuit dependency analysis on that point forward and just consume that BMI file as is. That would include pre-built bmi files for the standard library modules, or for module header units.
Yes, that is the goal. As indicated above though, I think a
solution that reflects a MIU's actual requirements for a
consistent parse is required to achieve that in practice.
Tom.
daniel