------=_Part_742_734148311.1456505762751
Content-Type: multipart/alternative;
 boundary="----=_Part_743_148272771.1456505762752"

------=_Part_743_148272771.1456505762752
Content-Type: text/plain; charset=UTF-8

On Friday, February 26, 2016 at 10:17:06 AM UTC-5, Matthew Woehlke wrote:
>
> On 2016-02-26 04:24, Igor Baidiuk wrote:
> > To me, module proposal can actually handle this. A compiler smart enough
> > can extract "public layer" from module definition and recompile
> dependents
> > only when that public layer is changed. And please note that that public
> > layer will also include at least size of private part. Something like
> > `private: char _1234__[PRIVATE_PART_SIZE];`
>
> How do modules work from a build system perspective, anyway?


Microsoft has an implementation of Modules, which shows how they
implemented it from a build system perspective
<https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-modules-in-vs-2015-update-1/>
..


> Does the
> compiler write out some new type of object file that becomes an input
> for files using those modules? (In particular, how does the build tool
> know when it needs to reinvoke the compiler for a particular source
> file, once modules are thrown into the mix?)
>
> Do you expect the compiler to be sufficiently clever as to not overwrite
> an existing compiled module file if the one it just produced has the
> same contents?
>

Um, yes. There's no reason for a compiler not to do a basic bit of hashing
on the compiled module file to check to see if it has genuinely changed.


> Or is the compiler expected to replace build tools entirely, i.e. to
> build a library, you invoke the compiler once, passing it *every source
> file used*, and expect the compiler to sort out what needs to be done?
>

.... why not?

Ordering of the build is important with modules, since you can't consume a
module that hasn't been built/updated. It makes sense to put this where it
belongs: in the compiler. If the compiler sees that a source file imports a
module that hasn't been looked at yet in this build, it can simply hold off
on further compilation until it gets to that module file.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3c2dd493-f298-424a-9f01-9f84fe7a1e08%40isocpp.org.

------=_Part_743_148272771.1456505762752
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, February 26, 2016 at 10:17:06 AM UTC-5, Matthew=
 Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-02-26 0=
4:24, Igor Baidiuk wrote:
<br>&gt; To me, module proposal can actually handle this. A compiler smart =
enough=20
<br>&gt; can extract &quot;public layer&quot; from module definition and re=
compile dependents=20
<br>&gt; only when that public layer is changed. And please note that that =
public=20
<br>&gt; layer will also include at least size of private part. Something l=
ike=20
<br>&gt; `private: char _1234__[PRIVATE_PART_SIZE];`
<br>
<br>How do modules work from a build system perspective, anyway?</blockquot=
e><div><br>Microsoft has an implementation of Modules, which shows <a href=
=3D"https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-modules-in-vs-2015=
-update-1/">how they implemented it from a build system perspective</a>.<br=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> Does the
<br>compiler write out some new type of object file that becomes an input
<br>for files using those modules? (In particular, how does the build tool
<br>know when it needs to reinvoke the compiler for a particular source
<br>file, once modules are thrown into the mix?)
<br>
<br>Do you expect the compiler to be sufficiently clever as to not overwrit=
e
<br>an existing compiled module file if the one it just produced has the
<br>same contents?<br></blockquote><div><br>Um, yes. There&#39;s no reason =
for a compiler not to do a basic bit of hashing on the compiled module file=
 to check to see if it has genuinely changed.<br>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">Or is the compiler expected to replace build=
 tools entirely, i.e. to
<br>build a library, you invoke the compiler once, passing it *every source
<br>file used*, and expect the compiler to sort out what needs to be done?<=
br></blockquote><div><br>... why not?<br><br>Ordering of the build is impor=
tant with modules, since you can&#39;t consume a module that hasn&#39;t bee=
n built/updated. It makes sense to put this where it belongs: in the compil=
er. If the compiler sees that a source file imports a module that hasn&#39;=
t been looked at yet in this build, it can simply hold off on further compi=
lation until it gets to that module file.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3c2dd493-f298-424a-9f01-9f84fe7a1e08%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c2dd493-f298-424a-9f01-9f84fe7a1e08=
%40isocpp.org</a>.<br />

------=_Part_743_148272771.1456505762752--
------=_Part_742_734148311.1456505762751--

.