<div>Agreed. Fewer TLAs lower the burden of entry for discussions, especially if we redefine existing terms for the sake of a TLA.</div><div><br></div><div>(TLA is a three letter acronym for three letter acronym ðŸ˜‰)</div><div><br></div>On Sun, Feb 17, 2019 at 12:10, Gabriel Dos Reis via Ext &lt;<a href="mailto:ext@lists.isocpp.org" class="">ext@lists.isocpp.org</a>&gt; wrote:<blockquote class="protonmail_quote" type="cite">  All - please let stop using 'LHU' or whatever that means.<br><br>They are just headers.  There is nothing legacy about them.<br><br>| -----Original Message-----<br>| From: Ext &lt;ext-bounces@lists.isocpp.org&gt; On Behalf Of Robert Maynard via<br>| Ext<br>| Sent: Friday, February 8, 2019 12:10 PM<br>| To: Ben Boeckel &lt;ben.boeckel@kitware.com&gt;; WG21 Tooling Study Group<br>| SG15 &lt;tooling@open-std.org&gt;<br>| Cc: Robert Maynard &lt;robert.maynard@kitware.com&gt;; Evolution Working<br>| Group mailing list &lt;ext@lists.isocpp.org&gt;<br>| Subject: Re: [Ext] [Tooling] [D1483] How CMake supports Fortran modules<br>| and its applicability to C++<br>|<br>| Personally I am concerned with the presumption that users of<br>| build-systems will understand that correct builds will only occur if<br>| they explicitly list LHU's.<br>| My expectation is that projects will try to convert over all/most of<br>| '#include' to LHU's and give-up when the tooling doesn't support that.<br>| I personally would like to see LHU detection/tracking be a well<br>| defined problem that is tractable for tools to solve without user<br>| intervention.<br>|<br>| On Fri, Feb 8, 2019 at 3:04 PM Ben Boeckel &lt;ben.boeckel@kitware.com&gt;<br>| wrote:<br>| &gt;<br>| &gt; On Fri, Feb 08, 2019 at 16:51:01 +0000, Gabriel Dos Reis wrote:<br>| &gt; &gt; Early feedback regarding section 6.3 and 6.4.<br>| &gt; &gt;<br>| &gt; &gt; Concern in 6.3:<br>| &gt; &gt; The description there is notional, not a requirement that needs to be<br>| &gt; &gt; followed by the letter by compilers. There is an alternative<br>| &gt; &gt; formulation that uses the notion or "semantics abstract graph" (term<br>| &gt; &gt; defined in the Modules TS) that does not rely on synthesized header<br>| &gt; &gt; unit.<br>| &gt;<br>| &gt; Sounds good. Some wordsmithing on the language at Kona to help clarify<br>| &gt; would be useful (tracking diffs of diffs are fun!).<br>| &gt;<br>| &gt; &gt; Concern in 6.4:<br>| &gt; &gt; The way to import of "header import" is that of using a precompiled<br>| &gt; &gt; header file.  If CMAKE already supports uses of PCHs, then the<br>| &gt; &gt; machinery is already there. For every import of a header H, there<br>| &gt; &gt; would be a rule for building say H.pch unless there is already a H.pch<br>| &gt; &gt; supplied by the system or other sources.<br>| &gt;<br>| &gt; If legacy header units must be mentioned explicitly to compilers, then<br>| &gt; CMake can just require such information as additional input in its<br>| &gt; input. The compiler can also output what files it would implicitly<br>| &gt; generate in its output and `collate` figures things out. It is the<br>| &gt; silent implicit stuff that's a problem. For the former, build tools can<br>| &gt; also just never say anything about legacy header units and the problem<br>| &gt; goes away.<br>| &gt;<br>| &gt; I'll update the paper with this information.<br>| &gt;<br>| &gt; &gt; Early feedback on section 7.<br>| &gt; &gt; That ask in 7.1 looks immensely reasonable to me; we have been<br>| &gt; &gt; considering similar for a while. The Visual C++ team would be happy to<br>| &gt; &gt; team up with other tool vendor to provide an open source version.<br>| &gt;<br>| &gt; I'm thinking that the tool mentioned on the Tcon from Apple would be<br>| &gt; useful here. On Slack, Michael Spencer mentioned a `clang-scan-deps`<br>| &gt; tool which sounds like it could also serve this purpose.<br>| &gt;<br>| &gt; Thanks,<br>| &gt;<br>| &gt; --Ben<br>| &gt; _______________________________________________<br>| &gt; Tooling mailing list<br>| &gt; Tooling@isocpp.open-std.org<br>| &gt;<br>| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.<br>| open-<br>| std.org%2Fmailman%2Flistinfo%2Ftooling&amp;amp;data=02%7C01%7Cgdr%40m<br>| icrosoft.com%7C940cc75d7af2406bbcf908d6943a3abd%7C72f988bf86f141af<br>| 91ab2d7cd011db47%7C1%7C0%7C636859375152809851&amp;amp;sdata=rsIZ0b<br>| HOJ60YJa2VQbJ6ysX35tp8UjZTESzRrh%2BeHv0%3D&amp;amp;reserved=0<br>| _______________________________________________<br>| Ext mailing list<br>| Ext@lists.isocpp.org<br>| Subscription:<br>| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.is<br>| ocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&amp;amp;data=02%7C01%7Cgdr%40<br>| microsoft.com%7C940cc75d7af2406bbcf908d6943a3abd%7C72f988bf86f141<br>| af91ab2d7cd011db47%7C1%7C0%7C636859375152809851&amp;amp;sdata=sRf4<br>| bJU04DdblP1J81mGpjIgA5ffKed6sM5Aqi0Tujc%3D&amp;amp;reserved=0<br>| Link to this post:<br>| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.is<br>| ocpp.org%2Fext%2F2019%2F02%2F8082.php&amp;amp;data=02%7C01%7Cgdr%4<br>| 0microsoft.com%7C940cc75d7af2406bbcf908d6943a3abd%7C72f988bf86f14<br>| 1af91ab2d7cd011db47%7C1%7C0%7C636859375152809851&amp;amp;sdata=4NT<br>| 3ZIbaGpfiX1Q4j%2FlqAFKVWwmR3cdfVEYZevuj0vg%3D&amp;amp;reserved=0<br>_______________________________________________<br>Ext mailing list<br>Ext@lists.isocpp.org<br>Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/ext<br>Link to this post: http://lists.isocpp.org/ext/2019/02/8156.php<br></blockquote><div><br></div><div><br></div>