<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 8 Feb 2019 at 20:45 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/02/2019 13.46, Tom Honermann wrote:<br>
&gt; I&#39;d like to understand more why ccache is impacted.  I don&#39;t have<br>
&gt; experience with the other tools, so can&#39;t comment on them.<br>
<br>
I assume, because the preprocessed output is no longer self-contained.<br>
<br>
The way ccache works is it *always* runs the preprocessor, then checks<br>
if the result of doing so generates an input that has been compiled<br>
previously. If so, rather than actually compile the TU again, it just<br>
takes the artifact that was generated last time. (Obviously, build flags<br>
are also part of the hashing.)<br>
<br>
Once you have modules, this is no longer the case. At best, ccache has<br>
to be able to find the modules that would be imported and hash them also.<br>
<br>
For ccache, this seems feasible, though it means ccache needs to be<br>
module-aware.<br>
<br>
@Corentin, are you suggesting that modules as proposed would be easier<br>
for ccache to implement than clang modules?<br></blockquote><div><br></div><div>Nope, tools will have to be adapted.</div><div>As long as it is possible and reasonable, it seems reasonable.</div><div>Without modification, ccache couldn&#39;t benefit from clang modules either</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I *believe* the problem for distributed builds (caveat: I have no<br>
experience here) is similar; currently, the &#39;master&#39; system runs the<br>
preprocessor and sends the result off to the &#39;slaves&#39; to be compiled. In<br>
this case, however, it would also need to send all the modules. Again,<br>
*probably* not intractable, but getting a bit more difficult. OTOH, I<br>
could imagine a setup where the &#39;master&#39; just does dependency scanning<br>
and packs up all the dependencies and sends that off. The &#39;slave&#39; would<br>
need to understand to use this &quot;bundle&quot; rather than the local file<br>
system to find dependencies, but this would also allow some of the<br>
preprocessing to be offloaded.<br></blockquote><div><br></div><div>Or send the sources, let the node duplicate BMI builds or a fine-tuned balance of the too,</div><div>you can probably get some parallelization by doing duplicated work.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <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>