On Fri, Apr 12, 2019 at 15:25:02 +0200, Boris Kolpackov wrote:
> > Do you have new data that would invalidate that recommendation?
>
> Google's use of Clang modules, which, if I understand correctly,
> are pretty much header units.

AFAIK, this is implicit module stuff. This is understood by those who
went down this route to be a sub-optimal solution and explicit modules
are just better.

> Ok, let me try. Imagine you are a build system trying to compile
> a TU that contains an import declaration like this:
>
> import hello.core;
>
> Before you can compile such a TU you need to make sure you have
> the BMI for the hello module ready and up-to-date. Since the set
> of imports in each TU changes frequently, in most cases it would
> be burdensome to expect the user to supply this information in a
> way that is easy for you to consume.

Agreed.

> Therefore, you are generally expected to extract this import set
> from the TU. While not exactly trivial, it is doable: you first
> preprocess the TU and then parse the result looking for the
> import declarations. Or, you can check if your compiler can do
> this for you (which is the original topic of this discussion).

It is my understanding that the 4 major vendors (GCC, Clang, MSVC, EDG)
are amenable to outputing the information in the format described here.
To my knowledge, at this point it is discussion on the actual
representation of the information.

> Ok, normal modules are good: you can obtain the import set, make
> sure the BMIs are ready, and compile the TU.
>
> Now let's say the TU contains an import declaration like this:
>
> import <hello/core.hpp>;
>
> The above approach of obtaining the import set (preprocess and
> parse) no longer works because header units may export macros
> and such macros may affect further preprocessing, for example:
>
> import <hello/core.hpp>; // exports HELLO_CORE
>
> #ifdef HELLO_CORE
> import <hello/extra.hpp>;
> #endif

This was discussed on the first SG15 meeting Kitware attended prior to
Kona because it was our main worry too. This is fine because `import
<hello/core.hpp>;` is semantically the same as `#include
<hello/core.hpp>` *for the purposes of preprocessing*. Therefore, the
preprocessor/scanner and it can tell that `HELLO_CORE` exists or not.
This is why the preprocess step does not require BMIs in general.

> > 4. Anything I am missing/forgetting?
>
> To me only the first approach (dynamic mapper) seems like a
> realistic option for a general-purpose build system (other
> options may be appropriate for compiler or codebase-specific
> build systems). Specifically, (2) feels too much like
> brittle compiler magic while (3) is too restrictive.

I guess the answer here is 4:

  - preprocessing does not require BMIs in a build using explicit
    modules

--Ben