Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-09-03 04:14:40

a user has asked me off-list if we could add support for precompiled headers
on msvc. Since I'd be intersted in PCH on gcc, I started to think how we can
do it.

The problem is that I never used PCH on windows, and never used then with gcc
(they were implemented recently). So, I'm not sure what the right way to use
them on either platfrom, and besides, there are some differences between
platforms. Here are my thoughts:


There are automatic and manual model. In the first, one adds a compiler
option, and PCH is automatically generated used. In the second, PCH must be
explicitly created. It's created by compiling an ordinary source file with an
extra option -- a name of header file. After including that header file
during compilation, internal compiler data is dumped to PCH. During compiling
other module, the name of that header file should also be specified. The
compiler skips the that include, restores internal data from PCH, and then
compiles the rest of file as usual.

I don't know which model is better, can anyone comment on that?

The problem with manual model is that it requires that all translation units
include the same "central header", and that's terrible for compilers without
PCH. Any ideas how to fight this? Note that wrapping the content of "central
header" with

#ifdef USE_PCH

might not work -- bjam does not care for preprocessor macros so any change in
headers included from the "central header" will cause complete rebuild. OTOH,
I'd think that header should only include standard headers, not the
application's headers.

Another danger is that if all translation units include the central header,
which grabs <vector>, <map>, <algorithm> and the like, then the programmers
might forget to add those include to translation units themself, so with
"USE_PCH" undefined there will be compile errors. Seems not good for
cross-platform programming.

2. gcc

Gcc, too, has two models. You start by compiling a header file. In the first
model, the compiled header is placed somewhere in include path, and if you
try to include that header, the precompiled version is used. That is, all
translation units still have to include a central header. In the second
model, you add "-include" option to the compiler, which cause it to load the
header before compiling the translation unit. This is handy, because it avoid
modifying all translation units. The problem is still that translation unit
which uses std::vector without include <vector> will compile fine with PCH,
but won't compile elsewhere.

3. Other compilers. I know that borland has pch and vaguely remember that is
had two models similiar to msvc's, but without the need to explicitly specify
the header. I can't find any information on, so comments are very

In conclusion, it's seems the the model with including a central header is the
lowest common denominator. Given that, the usage of pch can be something

pch all : all.h app.cpp : <toolset>msvc ;
pch all : all.h : <toolset>gcc ;
alias all ; # do-nothing catch for other compilers

exe main : main.cpp all ;

The user would have to include "all.h" from every source file and wrap in in
#ifdef "BOOST_USE_PCH" -- which will be set by Boost.Build automatically.


- Volodya


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at