> On May 18, 2023, at 4:37 PM, Daniel Ruoso <daniel_at_[hidden]> wrote:
>
> Em qui., 18 de mai. de 2023 às 15:19, Tom Honermann
> <tom_at_[hidden]> escreveu:
>> I agree with your interpretation of the standard. Since the standard is not concerned with build systems, implementation-defined was pretty much the only option for specifying which header files are importable (without introducing additional syntax).
>
> Yes. The specification does not make any attempt to define what makes
> a header importable or not.
>
> My understanding is that the intention was to model Explicit Clang
> Header modules, where the build system tells the compiler what the
> header units are, and early reports of adoption in the MSVC world
> seems to suggest my understanding is correct.

The intent was to enable such an implementation, but not at the expense of other ones.

MSVC has provided one implementation so far. Nothing prevents additional implementation strategies being added at a later time if demand/motivation arises.

>
> There is no specification on the relationship with the preprocessor
> state, particularly because there is a desire that the optimization is
> not required to create a BMI for every possible state at the time of
> the import, since that would result in almost no reuse, but at the
> same time it's difficult to specify that behavior without using a lot
> of build-system-specific words.

Agreed. There is also nothing in the standard that prohibits using the importing TU’s environment (by which I mean, the environment at the start of translation of the importing TU; not it’s state at the point of the import declaration).

It is true that implicitly built modules provide optimal reuse only in strictly controlled circumstances. However, in practice, they work quite well for many projects; most build systems are pretty regular with regard to the compiler command lines they generate. Don’t let the failure to scale to the needs of Google and other huge projects interfere with the easy adoption wins for smaller projects.

>
>> On 5/17/23 2:16 AM, 许传奇(夜灯) wrote:
>> But the consequence is that the C++ ecosystem is going to a more breaking state. For example, MSVC (or MSBuild?)
>> introduces header-units.json (https://learn.microsoft.com/en-us/cpp/build/reference/header-unit-json-reference?view=msvc-170).
>> And GCC has module map for named modules (I am not sure about gcc's state for header units). Clang has non-standard clang module
>> maps and doesn't have a solution for header units. It looks like things are not going right.
>
> I just posted P2898R0 so we can discuss in Varna on this whole
> situation. I think Importable Headers as a specification is not
> necessary to achieve the original goals of introducing Importable
> Headers, and instead we could probably achieve all the goals just
> saying the implementation can optimize source inclusions in different
> ways than just pasting the entire content, with implementation-defined
> caveats regarding the preprocessor state. The important bit being that
> the semantics of "souce inclusion" are still the "canonical" behavior,
> but the implementation is allowed to introduce optimizations with
> implementation-defined caveats where appropriate.

I mostly agree assuming that the differences that you have in mind correspond to the starting environment differences for importing TUs vs imported TUs.

>
> I was writing an email with a new thread to discuss P2989R0 when I saw
> this, I'll still start a new thread for that to make sure people are
> aware, but I think Importable Headers is not Universally
> Implementable.

I don’t know what you mean by this. There are multiple implementation strategies, some of which have been in use for many years.

Tom.

>
> daniel