Re: [jamboost] PCH support, main-targets vs. generators

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-09-08 03:16:41

Hi Michael,

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

That's true.

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

What about the opposite case of console applications, where it's desired to 
include in PCH all STL and Boost headers, but where each individual source 
file includes only fraction of STL/Boost headers.

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

I'm not sure this will work. The requirements on the 'alias' target are 
ignored. You'd really need some target which builds and returns object file 
(and the usage requirements you've written above, too). 

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

Metacomment: I think it's important to settle on one method of PCH usage which 
can be used everywhere. As it seems that central include method is the only 
universal, in the above example, we should use

<include>pch_o_directory

Even though "-include" is very cool.

But you miss one thing: you need to build the PCH file. So, again, I'm not 
sure that "alias" will do. I think we really need a special rule.

The biggest problem is 
1. The rule should be specific to each toolset
2. We also should return different usage requirements for each toolsets.
3. Usage requirements are computed inside instance of 'basic-target' class
4. Unlike generators, there's only one instance of 'basic-target' class per 
main-target-rule.

So, we need 'pch-target-class.compute-usage-requirement' to return different 
things depending on toolset used, and I don't know how to do this.
Generally, I'm not happy with the fact that we have two customization 
mechanism: generators and main target classes, which can be used in different 
cases, which is confusing. 

Maybe, we should decide to slowly move from main-target-class to generators 
only?

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

Did not think about it, but some solution will be possible.

> > Comments?
> >
> >From the source code perspective the two mechanisms are only
> > differentiated by
>
> 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.

I think we're still need the 'pch' rule, for reasons that we need pch file 
from h.

- Volodya