Boost logo

Boost-Build :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-15 01:54:53


Vladimir Prus wrote:
> On Wednesday 14 September 2005 20:22, Phillip Seaver wrote:
>
>>Vladimir Prus wrote:
>>
>>>Hmm.. why didn't you speak up before? It's the first time a user reports
>>>precompiled header support as a showstopper; if I knew it before such
>>>support
>>>would probably be already implemented.
>>
>>Just a note in case you do start implementing this -- I tried an
>>experiment yesterday and added <cflags>/YX ("Automatic Use of
>>Precompiled Headers") to my build and it won't work if you do -j2. Both
>>compiler processes try to open the .pch file and lock it. A couple of
>>weeks ago, I played with .pdb file generation and ran into the same
>>problem. I can create .pdb files as long as I don't use the -j option.
>
> 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.

cl pch.cpp -Yc"pch.h"

or, in BBv2:

# <pch-file> implies create-pch
obj pch : pch.cpp : <pch-file>pch.hpp ;

* 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 ;

* 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 ;

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. Thus, you would have:

obj pch : pch.cpp : <pch-file>pch.h ; # not using pch scanning

exe hello
:
hello.cpp # has pch.h, so uses PCH
non_pch.cpp # no pch.h, so don't use PCH
//pch # enable pre-compiled headers
;

Or, the slightly more complex:

obj pch : pch.cpp : <pch-file>pch.h ;

exe foo : foo.cpp //pch ;

exe bar
:
bar/main.cpp
//pch
;

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 ;

?

- Reece

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk