Thanks for the paper, Daniel.

I'm not sold on the use of an identifier in quite this way, but I think
there may be a useful idea here; one that is similar to an idea I heard
elsewhere at some point (unfortunately, I don't recall who to credit).

Let's consider a module interface unit (MIU) similar to the following
ridiculous example:

export module M;
export int f() {
#if !defined(ONE_THING)
   return 1;
#elif defined(GOTTA_BE)
   return 2;
#elif ANOTHER == 3
   return 3;
#elif __has_cpp_attribute(deprecated)
   return 4;
#elif __has_include("thing.h")
   return 5;
#else
   return sizeof(long);
#endif
}

I think compiler options can be effectively ignored in determining
whether a previously built BMI is compatible if we have the following
information available:

  * The language standard used to build the BMI.
  * The ABI (or at least the data model governing type sizes, type
    alignments, layout, etc...).
  * The (predefined) macros that were consulted when building the BMI.
    E.g., in a build for which f() returns 2, ONE_THING must not have
    been predefined, GOTTA_BE had to be predefined, and ANOTHER doesn't
    matter.
  * The attribute availability checks that were performed. E.g., in a
    build for which f() returns 4, the deprecated attribute must have
    been available, but carries_dependency doesn't matter.
  * The header file checks that were performed. E.g., in a build for
    which f() returns 5, a "thing.h" header file must have been
    available, but other header files don't matter.

Note that options that solely govern syntax probably aren't important
since the BMI reflects semantics, not syntax. (such options are
obviously important if a determination to build a new BMI is made; that
is a different concern than reuse though).

If a compiler had the ability to record which of the above
"environmental" elements were consulted *and* the compiler had a way to
report, for a given set of compiler options, the language standard
target, the ABI, the list of predefined macros and available attributes
in a form consumable to a build system, then the build system could
validate whether the requirements for a given BMI are met for reuse. The
build system would still have to evaluate cases like __has_include()
since the compiler obviously can't exhaustively provide a list.

To state the goal differently, what we're trying to do with BMI reuse is
to avoid re-parsing the MIU when a BMI is available that corresponds to
a parse of the MIU that would match the parse that would otherwise be
performed.

Tom.

On 4/26/22 10:02 AM, Daniel Ruoso via SG15 wrote:
> Hello,
>
> Trying to address a more narrow scope this time around. I was
> discussing with Ben about how the build system would know when a bmi
> would be reusable or not from a prebuilt library, and it turns out
> that is still a gap.
>
> IOW, as things stand right now the build system would have no option
> but to assume that no bmi in the system is compatible with the current
> build, and it would have to create rules for all the BMIs it needs.
>
> This paper tries to establish a mechanism by which the build system
> and the compiler can communicate in order to establish the identity of
> the format of the bmi file, and then establish that the identity of
> the format will become a part of the metadata when a library is
> distributed, which will allow the build system to consume a bmi
> shipped with a prebuilt library.
>
> https://wg21.link/P2581R0
>
> daniel
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15