On Fri, Feb 08, 2019 at 16:51:01 +0000, Gabriel Dos Reis wrote:
> Early feedback regarding section 6.3 and 6.4.
>
> Concern in 6.3:
> The description there is notional, not a requirement that needs to be
> followed by the letter by compilers. There is an alternative
> formulation that uses the notion or "semantics abstract graph" (term
> defined in the Modules TS) that does not rely on synthesized header
> unit.

Sounds good. Some wordsmithing on the language at Kona to help clarify
would be useful (tracking diffs of diffs are fun!).

> Concern in 6.4:
> The way to import of "header import" is that of using a precompiled
> header file. If CMAKE already supports uses of PCHs, then the
> machinery is already there. For every import of a header H, there
> would be a rule for building say H.pch unless there is already a H.pch
> supplied by the system or other sources.

If legacy header units must be mentioned explicitly to compilers, then
CMake can just require such information as additional input in its
input. The compiler can also output what files it would implicitly
generate in its output and `collate` figures things out. It is the
silent implicit stuff that's a problem. For the former, build tools can
also just never say anything about legacy header units and the problem
goes away.

I'll update the paper with this information.

> Early feedback on section 7.
> That ask in 7.1 looks immensely reasonable to me; we have been
> considering similar for a while. The Visual C++ team would be happy to
> team up with other tool vendor to provide an open source version.

I'm thinking that the tool mentioned on the Tcon from Apple would be
useful here. On Slack, Michael Spencer mentioned a `clang-scan-deps`
tool which sounds like it could also serve this purpose.

Thanks,

--Ben