<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Nov 12, 2013, at 3:33 PM, Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Wouldn't that mean that the build system had to launch clang for every pch file in noop builds? </div></blockquote><div><br></div><div>Not necessarily, It would definitely have to launch it if there is going to be a clang invocation using the PCH file.</div><br><blockquote type="cite"><div dir="ltr">And don't you want to force a full rebuild on compiler version changes anyhow?</div><div class="gmail_extra">
<br></div></blockquote><div><br></div><div>Again, not necessarily, incremental version changes are not supposed to change the semantics of your code. And the version is but one of multiple requirements for PCH verification.</div><br><blockquote type="cite"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 12, 2013 at 2:57 PM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:kyrtzidis@apple.com" target="_blank">kyrtzidis@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
Clang may reject using a PCH file for various reasons, e.g. because it was created from a different clang version, because an include file was modified, etc.<br>
<br>
I propose that we add an option like '--verify-pch /path/to/pch/file' in clang that when invoked will:<br>
-Load the given PCH file<br>
-Verify it (check compiler version, stat includes, etc.)<br>
-Return 0 on success or non-zero and a diagnostic error on failure.<br>
<br>
This can be used by a build system, if it so chooses, as part of its build dependencies calculation in order to verify that a PCH file is usable, and rebuild it if it is not.<br>
Clang is the "ultimate authority" on what constitutes a usable PCH file, so it makes sense to delegate to it.<br>
<br>
Apart from making the experience better when the PCH file becomes stale in ways the build system does not detect (e.g. due to different compiler version), another advantage of this approach is to allow us to reduce the amount of PCH verification that clang does by only doing it once at the beginning of the build process.<br>
Some time ago we stopped stat'ing the system headers during PCH verification, since we considered it not worth the cost to stat them for every clang invocation. If the build system checked once at the beginning and then informed clang on subsequent invocations that it doesn't need to re-verify the PCH again, we could bring back verification of system headers.<br>
<br>
Let me know what you think.<br>
<br>
-Argyrios<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>
_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote></div><br></body></html>