[cfe-commits] r68594 - /cfe/trunk/docs/PTHInternals.html

[Neil Booth]

Ted Kremenek wrote:-

> +<p>The high-level interface to generate a PTH file is the same as GCC's:</p>
> +
> +<pre>
> +  $ gcc -x c-header test.h -o test.h.gch
> +  $ clang -x c-header test.h -o test.h.pth
> +</pre>
> +
> +<p>A PTH file can then be used as a prefix header when a <tt>-include</tt>
> +option is passed to <tt>clang</tt>:</p>

-include-pth?

> +<p>In this example, <tt>clang</tt> will not automatically use the PTH file for
> +<tt>test.h</tt> since <tt>test.h</tt> was included directly in the source file
> +and not specified on the command line using <tt>-include</tt>.</p>

Again? If not I can't reconcile with

> +files.  Similarly, PTH files can be used as prefix headers using the <tt>-include-pth</tt> option:</p>

As an aside, having read your documentation, it would be perhaps
more user-friendly if the compiler would manage to figure out itself
if a precompiled header file were usable and if so use it automatically
(given a suitable command line option, that however wouldn't require
a file name).  I believe Borland and EDG use something like this
(and maybe MSVC), in conjunction with the #pragma hrdstop hint to
indicate up to where the PCH should be available until.  This doesn't
invalidate the advantages of your implementation that you cite later
in the text.

> +<li><p><em><tt>stat</tt> caching</em>: PTH files cache information obtained via
> +calls to <tt>stat</tt> that <tt>clang-cc</tt> uses to resolve which files are
> +included by <tt>#include</tt> directives. This greatly reduces the overhead
> +involved in context-switching to the kernel to resolve included files.</p></li>

Last time I looked this caching was a bit weak; though I forget why.

Neil.