Boost logo

Boost-Build :

From: Michael Stevens (Michael.Stevens_at_[hidden])
Date: 2004-09-07 11:55:50

On Friday 03 September 2004 11:14, Vladimir Prus wrote:

Thanks for bringing it up. I have a few suggestion on how to get some PCH
support using much of the existing BBv2 infrastructure.

> 1. MSVC
> 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 automatic mode is rather clever. It can work without any help from the
build system or source code. If the source files all have the same order of
#includes then this works perfectly.
If the order changes from file to file then the system will "pump",
continually building a new PCH.
Since automatic mode can work "out of the box" it is very useful. It can also
be ignored for this discussion as it needs no special BB support!

> 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

The general assumption is that headers in the PCH will be included by all
files anyway. This is generally "windows.h" and MFC stuff which takes 90% of
the compile time. For Windows apps this is usually done with the stdafx.hpp
and stdafx.cpp pair. So the question of how to optimise the structure in case
PCH are turned off does not arise! .

If it possible to specify per source file toolset options then the manual mode
can be used without any special BB infrastructure as following.

alias pch : pch.c :
<toolset>msvc <toolset>msvc:<cflags>"/Ycpch.h"
: :
# Usage requirements
<define>"INCLUDE_PCH" <toolset>msvc:<cflags>"/Yupch.h"

alias pch ;# other toolsets
exe helloworld : pch hello.c world.c ;

The source code hello.c and world.c would then start with
#include "pch.h"
#include others...
The include gaurds in other headers preventing double inclusion if PCH is

I haven't tried the above, but hopefully the concept is understandable!

It also relies on pch.cpp being built before the other source files and the
object output directory being the same.

> 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.

alias pch : pch.h : <toolset>gcc
: :
# Usage requirements
<toolset>gcc:<cflags>"-include "pch_o
exe helloworld : pch hello.c world.c ;

The difficulty with GCC is that we need to make either the "pch.o" (which
contains the precompiled header) or it's build directory appear on the
command line. No idea how to do this!

> Comments?

>From the source code perspective the two mechanisms are only differentiatedby
the need for "pch.c" for MSVC. I wonder if there is a way to remove this

So all this said I am hopeful that PCH's can be supported by generalalising
the exiting BBv2 mechanism. Maybe with a few additions to toolsets.jam files
to simplify the syntax for toolsets that support PCH.

Generality is always better then a special case!

All the best,


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