On 12/23/2011 09:51 PM, Warren Young wrote:
> On 12/23/2011 9:46 AM, Stefano Lattarini wrote:
>>
>> I know basically nothing about PCH,
>
> The only important thing to know is that it's a way to make the compiler dump
> its parse tree to disk during compilation so that it can simply reload that
> state from disk instead of rebuilding it from scratch for each module it
> builds.
>
> You might think of PCH as a similar optimization to that of a bytecode
> compiler
> for a dynamic language: it doesn't get you native code, like you can get with
> a
> traditional static language, but you still get a speed benefit by avoiding
> reparsing.
>
> PCH is most valuable with headers like STL which are commonly used across the
> program and are expensive to parse and reparse and re-reparse.
>
>> and it seems to me that it is not
>> a feature many users would require or employ.
>
> I think the idea is that if autoconf detects that PCH is available and
> automake generates the correct compiler commands to use it, it will be
> there "for free" to any user of the autotools. Builds just get magically
> faster.
>
> There's a monkey wrench, in that PCH doesn't work well if you don't
> organize your header files to take advantage of it. Say you have a
> program with 20 modules, and none of them have any commonality in their
> #include lines. PCH might make such a build *slower*. PCH gets its
> biggest benefit when you can make the includes as similar as possible
> across modules, at least up to a point.
>
Thanks for the explanation. With my present reply, I'm registering it in the
appropriate entry of the bug tracker, for future reference.
> Visual C++ avoids this trap by generating a header file for the project which
> you're supposed to #include in every module, and in which goes #includes for
> the most commonly used things. (stdio.h, windows.h...) The project is
> configured to only generate PCH output for that one header, so there is none
> of the cache thrashing that happens in my 20-modules example.
>
> I'm sure you care nothing for Visual C++,
>
Not personally, but the latest versions of automake are starting to provide
support to allow/facilitate compilation with MSVC on MSYS/MinGW (credit for
this mostly goes to Peter Rosin). The NEWS entries from the latest 1.11.2
version of Automake contain:
- The `compile' script now converts some options for MSVC for a better
user experience. Similarly, the new `ar-lib' script wraps Microsoft lib.
- New macro AM_PROG_AR that looks for an archiver and wraps it in the new
'ar-lib' auxiliary script if the selected archiver is Microsoft lib.
> but most of the people begging for PCH support are probably coming from
> this world.
> Bottom line, such a feature, if ever added, should probably be optional.
>
Thanks for the tip.
Regards,
Stefano
