PATCH: Install four PCH files instead of one

[Geoff Keating]

> Date: Wed, 16 Apr 2003 22:52:40 -0500
> From: Benjamin Kosnik <bkoz@redhat.com>
> Cc: geoffk@geoffk.org, libstdc++@gcc.gnu.org
> X-OriginalArrivalTime: 17 Apr 2003 03:54:13.0554 (UTC) FILETIME=[0286E920:01C30495]
> 
> 
> >> I think the fallout will be pretty minimal, but I'd like to get a round
> >> of testing in before Friday and the weekend sets in.
> >
> >Agreed.
> 
> OK. It's in.
> 
> >To ensure that flags are properly overrode in all cases, I changed the
> >list to: "-O0 -g0", "-O2 -g0", "-O0 -g", "-O2 -g".
> 
> Sounds good.
> 
> >How about this (perhaps better than adding -Winvalid-pch when you have
> >multiple PCH options to reduce the noise; and documented as a valid
> >technique):
> >
> >	echo '#error Failure to use PCH file as requested.' > ${pch_input}; \

Yes, that's a valid technique.

I think it might be even better to have the actual contents used to
build the PCH file in the corresponding header.  One problem that can
happen otherwise is that projects become dependent on the PCH file, by
not including headers that are actually needed.

> >A #warning might be better still.  Perhaps, when multiple PCH files
> >are consider, no reason should be presented why 3/4 don't work.  If
> >4/4 don't work then dump all reasons.

I do want to improve PCH error handling---in particular, the "file not
found" error message should be "found a PCH file, but didn't use it
for this reason, then couldn't find a real header".

> I guess my use of pch_input is unclear.
> 
> pch_input == stdc++.h
> pch_output == stdc++.h.gch
> 
> That part is ok. However, $(src)/*/$(pch_input) is an include file that
> includes all the C++ includes. And $(bld)/*/$(pch_input) is an empty file.
> 
> Note that ${pch_input} isn't installed, and on purpose. I'd toyed with
> not even having it, but then for 26_numerics/complex_value (and the
> thread tests, which pass -pthread), which is compiled with -O0, the one
> generated pch file can't be used. Since "-include $bld/$(pch_output)" is
> passed to all testsuite files, if $(pch_output) cannot be used, and
> there isn't some $(pch_input) to use instead, compilation fails. This
> just adds extra fails, when in reality nothing is really wrong, just
> that the generated PCH file cannot be used.
> 
> Thus, the dummy file. Your solution is to instead make a bunch of PCH
> files, each with different compilation options.
> 
> I'm not quite sure what to do. Part of me feels that PCH is an
> optimization (and a useful one), and that if it doesn't work 100% of the
> time, and that a silent failure when attempting to use it still results
> in correct behavior, well then.... not something to get crazy about. 
> 
> I'm not quite sure what people expect with PCH, or what other's
> experiences are. I am unaware of EDG based compilers shipping with a PCH
> at all, assuming that the end users will do what is best for them, and I
> think that Metrowerks just ships one (but that it works for all
> optimization levels?) What does Apple do?

Metrowerks ships one, and if you want to change your settings then
you need to (manually) build one for the new settings.

Apple is still deciding, but the current plan is to not ship any PCH
files and have them built as part of individual projects.

-- 
- Geoffrey Keating <geoffk@geoffk.org>