On Wed, Apr 10, 2019 at 12:14:33 +0200, Boris Kolpackov wrote:
> Ben Boeckel via Modules <modules_at_[hidden]> writes:
>
> > Is there anything folks would like me to discuss?
>
> I am trying to understand if/how this will help/work with header
> units and include translation.

So my expectation is that CMake would have to know what headers/MIU
files are available via usage requirements or pkg-config variables.
Something like this:

    target_cxx_modules(Imported::Target
      PUBLIC
        avail.mod1=/path/to/some.miu
        avail.mod2=/path/to/some/other.miu)

The `miu` extension here is for "module interface unit". How these are
generated/provided is not yet known.

When this target is used (not just available), CMake would generate
rules to scan these `.miu` files and to build the BMIs for them. The
scan rules would be hooked up via dependencies on the collate output's
dependencies. Nothing would depend on the BMI rules except where
scanning determines that they are necessary.

> My understanding is this dependency information will be based
> on the preprocessed output. However, header unit BMIs have to
> be made available during preprocessing (because they may export
> macros that could affect further preprocessing). My recollection
> from earlier discussions is that while this format may (must?)
> include the dependency information for header units (and take
> into account include translation), it does not try to solve/help
> with the "how are those header unit BMIs made available" problem.

Since BMIs are not generally sharable, every build would need to support
generating BMIs from external files, header or MIU. Since I only plan on
doing explicit modules in CMake, it means that something like
`import <boost/version.hpp>;` would not work without the Boost imported
target saying something like:

    <boost/version.hpp>=$prefix/include/boost/version.hpp

in its usage requirements. How CMake can help provide this information
can be discussed, but I think it is best that it is all explicit.

--Ben