[cfe-dev] RFC: '--verify-pch /path/to/pch/file' to verify that a PCH file can be used

[Nico Weber]

Wouldn't that mean that the build system had to launch clang for every pch
file in noop builds? And don't you want to force a full rebuild on compiler
version changes anyhow?


On Tue, Nov 12, 2013 at 2:57 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com>wrote:

> Hi all,
>
> 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.
>
> I propose that we add an option like '--verify-pch /path/to/pch/file' in
> clang that when invoked will:
>   -Load the given PCH file
>   -Verify it (check compiler version, stat includes, etc.)
>   -Return 0 on success or non-zero and a diagnostic error on failure.
>
> 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.
> Clang is the "ultimate authority" on what constitutes a usable PCH file,
> so it makes sense to delegate to it.
>
> 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.
> 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.
>
> Let me know what you think.
>
> -Argyrios
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131112/ace2adc1/attachment.html>