<div dir="ltr"><div>JeanHeyd:</div><div><br></div><div>&gt; Neither of these perform full semantic analysis to help get the build 
system going (they do preprocessing + a few other steps, but never 
semantic analysis), so I&#39;m curious where I would find this information?</div><div><br></div><div>Ninja parses the output from /showIncludes and -MMD, so it is using the preprocessor flags to do it, but that&#39;s not really the point: A full compilation is executed for the first pass before this information is available, and a byproduct of that compilation is the emission of the &quot;effects-the-output&quot; dependency information. Ninja doesn&#39;t have a separate &quot;get the dependencies&quot; stage that it runs before compilation. Even if there were an --emit-dep-info option to the compiler that performed full semantic analysis to get deep dependency information, this model would be fully supported.</div><div><br></div><div>Boris:<br></div><div><br></div><div>&gt; It can&#39;t handle auto-generated headers.</div><div><br></div><div>This is fully supported with order-only dependencies. This is not even a &quot;pre-build&quot; step, it purely effects the ordering when enqueueing edges for execution as part of the regular build.<br></div><div><br></div><div>&gt; It doesn&#39;t fit well with implementing support for distributed compilation or ignorable change detection.</div><div><br></div><div>It works perfectly fine. For distributed build, you hand the TU to the distributed tool and it will spit back the dependency information. For ignorable changes, nothing about a just-in-time dependency info model requires timestamps be used as the determiner of &quot;out-of-date&quot;-ness.</div><div><br></div><div>&gt; It won&#39;t work for C++ modules, unless you are prepared to go with the &quot;compiler calls back into the build system&quot; approach</div><div><br></div><div>&gt; I would be interested to learn how this will work</div><div><br></div><div>I&#39;ve been formulating what this will look like for a while. I have several ideas in mind, but going into them will send the thread pretty far off track (if it hasn&#39;t gone too far already).<br> </div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 19, 2018 at 1:58 AM Boris Kolpackov &lt;<a href="mailto:boris@codesynthesis.com">boris@codesynthesis.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">Colby Pike &lt;<a href="mailto:vectorofbool@gmail.com" target="_blank">vectorofbool@gmail.com</a>&gt; writes:<br>
<br>
&gt; Modern build tools such as Ninja grab the dependency information for a<br>
&gt; translation unit as part of invoking the compiler command, not by running<br>
&gt; the preprocessor separately. I&#39;m preparing a post on how Ninja builds and<br>
&gt; performs dependency analysis, which I believe is the currently optimal way<br>
&gt; to do it.<br>
<br>
This &quot;header dependency information as a by-product of compilation&quot;<br>
approach has a number of problems:<br>
<br>
1. It can&#39;t handle auto-generated headers.<br>
<br>
2. It doesn&#39;t fit well with implementing support for distributed<br>
   compilation or ignorable change detection.<br>
<br>
3. It won&#39;t work for C++ modules, unless you are prepared to go with the<br>
   &quot;compiler calls back into the build system&quot; approach. <br>
<br>
So I believe next-generation C++ build systems will instead use a<br>
different compilation model (and build2 already does). This fragment<br>
from my CppCon talk has the details:<br>
<br>
<a href="https://youtu.be/cJP7SSLjvSI?t=2332" rel="noreferrer" target="_blank">https://youtu.be/cJP7SSLjvSI?t=2332</a><br>
<br>
<br>
&gt; There may be some tweaks with the addition on modules, but it will still<br>
&gt; be applicable.<br>
<br>
I would be interested to learn how this will work.<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>