<div dir="ltr"><div>JeanHeyd:</div><div><br></div><div>> 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'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'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 "effects-the-output" dependency information. Ninja doesn't have a separate "get the dependencies" 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>> It can't handle auto-generated headers.</div><div><br></div><div>This is fully supported with order-only dependencies. This is not even a "pre-build" step, it purely effects the ordering when enqueueing edges for execution as part of the regular build.<br></div><div><br></div><div>> It doesn'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 "out-of-date"-ness.</div><div><br></div><div>> It won't work for C++ modules, unless you are prepared to go with the "compiler calls back into the build system" approach</div><div><br></div><div>> I would be interested to learn how this will work</div><div><br></div><div>I'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'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 <<a href="mailto:boris@codesynthesis.com">boris@codesynthesis.com</a>> 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 <<a href="mailto:vectorofbool@gmail.com" target="_blank">vectorofbool@gmail.com</a>> writes:<br>
<br>
> Modern build tools such as Ninja grab the dependency information for a<br>
> translation unit as part of invoking the compiler command, not by running<br>
> the preprocessor separately. I'm preparing a post on how Ninja builds and<br>
> performs dependency analysis, which I believe is the currently optimal way<br>
> to do it.<br>
<br>
This "header dependency information as a by-product of compilation"<br>
approach has a number of problems:<br>
<br>
1. It can't handle auto-generated headers.<br>
<br>
2. It doesn't fit well with implementing support for distributed<br>
compilation or ignorable change detection.<br>
<br>
3. It won't work for C++ modules, unless you are prepared to go with the<br>
"compiler calls back into the build system" 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>
> There may be some tweaks with the addition on modules, but it will still<br>
> 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>