Re: [jamboost] PCH support

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

Hello,
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
#ifdef INCLUDE_PCH
#include "pch.h"
#endif
#include others...
The include gaurds in other headers preventing double inclusion if PCH is 
enabled.

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
<define>"INCLUDE_PCH"
EITHER
<toolset>gcc:<cflags>"-include "pch_o
OR
<include>pch_o_directory
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 
requirement.

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,
Michael