<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 14, 2019 at 8:42 AM Matthew Woehlke &lt;<a href="mailto:mwoehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 13/02/2019 10.26, JF Bastien wrote:<br>
&gt; On Wed, Feb 13, 2019 at 7:07 AM Ben Boeckel wrote:<br>
&gt;&gt; On Tue, Feb 12, 2019 at 14:01:34 -0800, JF Bastien wrote:<br>
&gt;&gt;&gt; I&#39;m confused as to why headers suddenly stop working.<br>
&gt;&gt;<br>
&gt;&gt; Because if, as a project, I port over to modules, I *still* have to<br>
&gt;&gt; maintain headers? I may as well not do modules at all at that point just<br>
&gt;&gt; due to maintenance costs.<br>
&gt; <br>
&gt; Seems something a tool can do, if I understand what you have in mind.<br>
<br>
...then let a tool do it.<br>
<br>
Oh, look! You&#39;ve invented a portable, intermediate representation!<br></blockquote><div><br></div><div>Invention requires novelty. Extracting a header from source isn&#39;t novel.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(Note on possible point of confusion: &quot;intermediate representation&quot; as I<br>
am using it should not be assumed to have any relation to &quot;IR&quot; in<br>
current compiler parlance. It means only what it literally means;<br>
something which exists between the original user-authored source files<br>
and BMI&#39;s.)<br>
<br>
Modules won&#39;t work unless we retain having separate files for the<br>
interface (what is externally consumed) and implementation (what is not<br>
distributed). Neither shipping the complete source code nor shipping<br>
just BMI&#39;s are feasible options for at least some audiences.<br>
<br>
As previously stated, I was under the impression that some people felt<br>
strongly that one of their &#39;goals for modules&#39; was to be able to get rid<br>
of that distinction at the managed-source level (i.e. the files that are<br>
developer-authored would not make such a distinction). If that is indeed<br>
a goal, then we *must* have a PMIR¹. I&#39;m not sure what form that will<br>
take; it *may* look suspiciously like a C++ &quot;header&quot; file that is<br>
automatically generated by the compiler.<br>
<br>
AFAICT, the only plausible alternative is to require folks to maintain<br>
the interface/implementation split in their original sources, and to<br>
continue to ship the inteface source files. Which... is basically what<br>
we do today, and contradicts something I had understood to be a desired<br>
goal of modules. I&#39;m okay with that, but if that&#39;s the case, let&#39;s<br>
please state that clearly.<br>
<br>
(¹ Portable Module Interface Representation)<br>
<br>
&gt;&gt; For projects which don&#39;t build zlib++ (as a strawman) as part of their<br>
&gt;&gt; build and instead assume that there is one provided by the system, yes.<br>
&gt; <br>
&gt; I don’t think that’s true, based on what my platform offers.<br>
<br>
What is shipped as the module interface? (Is that the same thing that<br>
would be shipped in an IS-modules world?)</blockquote><div><br></div><div>Our paper covers how clang modules work. We use modules internally (not for every project), and we ship headers + binary for some frameworks. Developers on our platform can use modules if they so desire. Some of our headers are massaged by a variety of tooling.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Can it be used by every<br>
compiler?</blockquote><div><br></div><div>Depends what you mean by &quot;it&quot;. Headers and linking work just fine. I also don&#39;t think this is relevant.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What does the developer need to do to create/maintain said<br>
artifacts?<br></blockquote><div><br></div><div>Modularization requires work, and there are some tools that try to help. Once you&#39;ve modularized, there&#39;s no unusual amounts of work required.</div><div><br></div><div>You should probably talk to Bruno in Kona. I think this would help demystify things even more that what we&#39;ve tried with our paper.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Matthew<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="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
</blockquote></div></div>