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:

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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15