<div dir="ltr">Sorry, Legacy Header Units<div><br></div><div>Referring specifically to that part of the modules proposal</div><div><br></div><div><font face="monospace">When a #include appears within non-modular code, if the named header file is known to correspond to a legacy header unit, the implementation treats the #include as an import of the corresponding legacy header unit. The mechanism for discovering this correspondence is left implementation-defined; there are multiple viable strategies here (such as explicitly building legacy header modules and providing them as input to downstream compilations, or introducing accompanying files describing the legacy header structure) and we wish to encourage exploration of this space. An implementation is also permitted to not provide any mapping mechanism, and process each legacy header unit independently</font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div><div>The list of such headers can only be maintained manually or synthesized by scanning the complete dependency tree - rather than be extractable from an arbitrary individual source file.</div><div><div><br><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 8 Feb 2019 at 18:20 Gabriel Dos Reis &lt;<a href="mailto:gdr@microsoft.com">gdr@microsoft.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-6686051451688645092WordSection1">
<p class="MsoNormal">I cannot understand what you are saying because I don’t know what LHU is, and I don’t understand the second bullet and why that is the case.<u></u><u></u></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_-6686051451688645092WordSection1">
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Corentin &lt;<a href="mailto:corentin.jabot@gmail.com" target="_blank">corentin.jabot@gmail.com</a>&gt; <br>
<b>Sent:</b> Friday, February 8, 2019 9:18 AM<br>
<b>To:</b> Evolution Working Group mailing list &lt;<a href="mailto:ext@lists.isocpp.org" target="_blank">ext@lists.isocpp.org</a>&gt;<br>
<b>Cc:</b> <a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>; WG21 Tooling Study Group SG15 &lt;<a href="mailto:tooling@open-std.org" target="_blank">tooling@open-std.org</a>&gt;; Gabriel Dos Reis &lt;<a href="mailto:gdr@microsoft.com" target="_blank">gdr@microsoft.com</a>&gt;<br>
<b>Subject:</b> Re: [Ext] [Tooling] [D1483] How CMake supports Fortran modules and its applicability to C++<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Nice document.<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><span style="color:#212121">6.4  I believe LHU imported through include will need to be identified by either</span><u></u><u></u></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal">
<span style="font-size:10.0pt;color:#212121">Having a manually maintained list of LHU</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-size:10.0pt;color:#212121">Parsing all files in the projects/dependency and assuming that files that are not imported with import at least once are not LHU</span><u></u><u></u></li></ul>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;color:#212121">I agree that letting the compiler decides to treat an include as an LHU without the blessing of the build system would be asking for trouble</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, 8 Feb 2019 at 17:51 Gabriel Dos Reis via Ext &lt;<a href="mailto:ext@lists.isocpp.org" target="_blank">ext@lists.isocpp.org</a>&gt; wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Early feedback regarding section 6.3 and 6.4.<br>
<br>
Concern in 6.3:<br>
The description there is notional, not a requirement that needs to be followed by the letter by compilers.<br>
There is an alternative formulation that uses the notion or &quot;semantics abstract graph&quot; (term defined in the Modules TS) that does not rely on synthesized header unit.<br>
<br>
Concern in 6.4:<br>
The way to import of &quot;header import&quot; is that of using a precompiled header file.  If CMAKE already supports uses of PCHs, then the machinery is already there.<br>
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.<br>
<br>
<br>
Early feedback on section 7.<br>
That ask in 7.1 looks immensely reasonable to me; we have been considering similar for a while.
<br>
The Visual C++ team would be happy to team up with other tool vendor to provide an open source version.<br>
<br>
-- Gaby<br>
<br>
| -----Original Message-----<br>
| From: <a href="mailto:tooling-bounces@open-std.org" target="_blank">tooling-bounces@open-std.org</a> &lt;<a href="mailto:tooling-bounces@open-std.org" target="_blank">tooling-bounces@open-std.org</a>&gt; On<br>
| Behalf Of Ben Boeckel<br>
| Sent: Friday, February 8, 2019 7:55 AM<br>
| To: WG21 Tooling Study Group SG15 &lt;<a href="mailto:tooling@open-std.org" target="_blank">tooling@open-std.org</a>&gt;<br>
| Subject: [Tooling] [D1483] How CMake supports Fortran modules and its<br>
| applicability to C++<br>
| <br>
| Hi,<br>
| <br>
| Here is copy of Kitware&#39;s paper to be discussed at Kona. I have a PDF,<br>
| but it was too large to attach to the list. I&#39;ll be at Kona, but the<br>
| other authors are not able to make it.<br>
| <br>
| An HTML version is hosted here:<br>
| <br>
| <br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmath" target="_blank">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmath</a><br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstuf.fedorapeople.org&amp;data=02%7C01%7Cgdr%40microsoft.com%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876390497&amp;sdata=L7ZPTmCXKH85RsKWcY%2B9LDdyZj5pvc1yDUPyKMnHlvE%3D&amp;reserved=0" target="_blank">
stuf.fedorapeople.org</a>%2Ffortran-modules%2Ffortran-<br>
| modules.html&amp;amp;data=02%7C01%7Cgdr%<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&amp;data=02%7C01%7Cgdr%40microsoft.com%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876400493&amp;sdata=AaN44dE%2BTPGemUuYNNcZ34BU48TuqVavbBusc%2BzTR1g%3D&amp;reserved=0" target="_blank">40microsoft.com</a>%7Cd49f0fb63<br>
| aac4ce886ff08d68dddd8b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7<br>
| C1%7C636852381303060160&amp;amp;sdata=ltkTtPf84tUk76Am5swiz6eNBGqZW<br>
| ydRfDoswsYEmlA%3D&amp;amp;reserved=0<br>
| <br>
| Feedback welcome.<br>
| <br>
| Thanks,<br>
| <br>
| --Ben<br>
| _______________________________________________<br>
| Tooling mailing list<br>
| <a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww" target="_blank">
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww</a>.<br>
| open-<br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstd.org&amp;data=02%7C01%7Cgdr%40microsoft.com%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876400493&amp;sdata=Tp1cNviVwPObjeu9KZHdPMmQ7PyLZ0cp7YkVRqRVOVo%3D&amp;reserved=0" target="_blank">
std.org</a>%2Fmailman%2Flistinfo%2Ftooling&amp;amp;data=02%7C01%7Cgdr%40m<br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ficrosoft.com&amp;data=02%7C01%7Cgdr%40microsoft.com%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876410487&amp;sdata=fiMwau40AAli3Peve2N5QsogDawYHvMQI9nYYp9jOwk%3D&amp;reserved=0" target="_blank">
icrosoft.com</a>%7Cd49f0fb63aac4ce886ff08d68dddd8b0%7C72f988bf86f141af9<br>
| 1ab2d7cd011db47%7C1%7C1%7C636852381303060160&amp;amp;sdata=YLene6t<br>
| qdjuV7ad%2BAHf5kceett%2F1Whqj7Db0zka470g%3D&amp;amp;reserved=0<br>
_______________________________________________<br>
Ext mailing list<br>
<a href="mailto:Ext@lists.isocpp.org" target="_blank">Ext@lists.isocpp.org</a><br>
Subscription: <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&amp;data=02%7C01%7Cgdr%40microsoft.com%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876410487&amp;sdata=toDBF8LGJcMAW3EI%2FlAd%2FiqS1ZR3XcB3sfDDnYgxDx0%3D&amp;reserved=0" target="_blank">
http://lists.isocpp.org/mailman/listinfo.cgi/ext</a><br>
Link to this post: <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2019%2F02%2F7507.php&amp;data=02%7C01%7Cgdr%40microsoft.com%7C74a4548c1eb941d6084308d68de963eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852430876420478&amp;sdata=JWYcKaPE4HXfpz5PBmfOeAPYGlzRTF0uv3bTINwZQzA%3D&amp;reserved=0" target="_blank">
http://lists.isocpp.org/ext/2019/02/7507.php</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div></div></blockquote></div>