RE: [jamboost] Precompiled headers

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-22 12:37:29

Vladimir Prus wrote:
>On Thursday 15 September 2005 10:54, Reece Dunn wrote:
>
> > > When we talked about it before, the general agreement was to never use
> > > automatic pch, but instead use manual mode. MSVC users said it's much
> > > more reliable.
> >
> > It also gives you greater control. There are 3 options (disregarding
> > automatic mode):
> >
> > * create-pch -- generate PCH compiled with this source, giving the PCH
> > a specific name. E.g.
> >
> > # <pch-file> implies create-pch
> > obj pch : pch.cpp : <pch-file>pch.hpp ;
>
>Can't be have
>
> pch my_pch : pch.hpp ;
>
>and automatically create "pch.cpp" containing just a single include?

It is possible, but MFC/ATL sometimes put other stuff in their generated PCH 
files, so people might expect to be able to alter their pch.cpp. This can be 
solved by having:

pch my_pch : pch.hpp ; # auto-generate pch.cpp

and

pch my_pch : pch.hpp : pch.cpp ; # use pre-existing pch.cpp

> > * use-pch -- this tells the compiler that the file is using PCHs, so it
> > looks for
> >
> > #include "pch.h" // or whatever <pch-file> is set to
> >
> > MSVC option is -Yu. In general, if you have PCHs enabled, PCH is on by
> > default, i.e.
> >
> > <pch-file>[something]/<pch>default : -Yu ;
>
>Should the -Yu option specify the name of produced PCH file, or original
>header file, or what? And where the create PCH file is placed?

-Yu"pch.hpp" specifies the original header.
-Fp".../pch.pch" specifies the location of the pre-compiled header.

> > * don't-use-pch -- this tells the compiler there isn't an include for
> > pch.h and so it shouldn't use PCHs. In general, you would need to
> > control this for a few files only:
> >
> > obj non_pch : non_pch.cpp : <pch>off ;
>
>It might be possible to just don't specify <pch-file> on such target, no?

<pch-file> would be specified on the exe/lib target, enabling PCHs for all 
*.cpp targets. This is what you would want because most/all files will use 
PCHs. There may be some files you don't want to use PCHs for, so it should 
be possible to turn them off for those files. For example:

exe my_exe : [ glob *.cpp ] //my_pch ;
obj no_pch : no_pch_support.cpp ;

> > Therefore, we have the following:
> >
> > <pch-file> -- A text string that is the PCH file to use. If this is
> > empty, PCHs are off.
> > <pch>default off -- Used to control files that use PCHs.
> >
> > NOTE: Since BBv2 is doing #include scanning, it should be possible to
> > automatically scan for <pch-file> in the top-level source file and if
> > found, enable PCHs. This would be much simpler to use and would be the
> > preferred way to go, but it would make the implementation more complex
> > and I don't know enough about incluse scanning internals to implement
> > this.
>
>That's very hard, I'm afraid.

Oh well. I was just throwing around ideas :).

> > Alternative: if you could specify the PCH source file as a <pch-source>
> > option, whast happens if you have something like:
> >
> > exe foo : foo.cpp : <pch-source>pch.cpp <pch-file>pch.h ;
> > exe bar : bar.cpp : <pch-source>pch.cpp <pch-file>pch.h ;
>
>I don't understand the question, sorry.

I was thinking about the possibility of conflicts if you share the same PCH 
with different features.

===

I will see if I can get something like what we are suggesting to work. I 
will try it first on msvc and then see if I can extend that to GCC and 
CodeWarrior. I'll post what I find.

- Reece