Personally I am concerned with the presumption that users of
build-systems will understand that correct builds will only occur if
they explicitly list LHU's.
My expectation is that projects will try to convert over all/most of
'#include' to LHU's and give-up when the tooling doesn't support that.
I personally would like to see LHU detection/tracking be a well
defined problem that is tractable for tools to solve without user
intervention.

On Fri, Feb 8, 2019 at 3:04 PM Ben Boeckel <ben.boeckel_at_[hidden]> wrote:
>
> 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
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling