On Tue, Mar 05, 2019 at 15:46:13 +0200, Boris Kolpackov wrote:
> I agree with Nathan, all these "provides", "logical-provides", etc.,
> feel unnecessarily elaborate and confusing. In comparison, here is
> what we have in build2:

See my reply to Nathan for my response to this.

> While this may need to be extended to support partitions, it suggest a
> couple of things your description is missing that we found useful:

My code in CMake doesn't care about this. About the only difference
between modules and non-modules is whether they have a `provides` field.
That is then handled later when we write out the Ninja and modmap files
and non-modules just drop out gracefully.

> 1. Translation unit type (module interface, module implementation,
> or non-modular).

CMake knows based on the command line it generated. Why would any other
tool not know? In any case, I wouldn't know what to do with the
information in the code path CMake deals with this. Or is it as a
convenience for tools that aren't builders (like static analysis)? Not
sure that'd work there either since the command line is different
between header units and non-header units (in GCC) anyways, so one has
to know ahead of time in the first place.

> 2. Whether import is re-exported.

Why would this matter at all? CMake doesn't care right now. I'll add a
test case to my sandbox repo for reexporting a module.

> I also assume this does not and is not mean to deal with header
> modules (I don't believe they can be handled with a pre-scan
> since they affect the preprocessor).

Header modules are supported by this format as well (but CMake needs
syntax updates for it, so is currently unrealized). The scan can find
headers using the same logic as it would for #include. The
implementation may be more involved though. I don't know.

--Ben