Re: [Boost-build] pch-support for gcc, msvc and dmc

From: Ilya Sokolov (fal_delivery_at_[hidden])
Date: 2006-09-11 03:31:46

Vladimir Prus wrote:
> On Monday 28 August 2006 16:55, Ilya Sokolov wrote:
> 
>>>>if you need, i can send you my project for testing. it builds 'fox' gui
>>>>library under msvc, borland, dmc and mingw
>>>
>>>That would be appreciated. In particular, we'll be able to measure how
>>>much of performance boost that gives.
>>
>>hi!
>>
>>this e-mail does not fit to the mailing list, so i've sent it directly.
>>
>>see attached develop.zip that contains:
>>- patched bbv2 from head of boost cvs
>>- latest stable fox release with jamfiles
>>- readme.txt
> 
> 
> Hi Ilya,
> I've tried to build this example and got the following:
> 
> MkDir1 bin
> MkDir1 bin/third_party
> MkDir1 bin/third_party/fox
> MkDir1 bin/third_party/fox/gcc
> MkDir1 bin/third_party/fox/gcc/debug
> gcc.compile.c++.pch bin/third_party/fox/gcc/debug/xincs.h.gch
> third_party/fox/include/xincs.h:73:49: error: io.h: No such file or directory
> third_party/fox/include/xincs.h:178:21: error: windows.h: No such file or 
> directory
> third_party/fox/include/xincs.h:180:22: error: winsock2.h: No such file or 
> directory
> third_party/fox/include/xincs.h:182:56: error: commctrl.h: No such file or 
> directory
> third_party/fox/include/xincs.h:183:22: error: shellapi.h: No such file or 
> directory
> third_party/fox/include/xincs.h:318:22: error: winspool.h: No such file or 
> directory
> 
> I suppose that file only works on windows.
> 
> Anyway, I've took a look on the PCH logic itself. I think the biggest issue 
> now is that pch.jam contains a lot rules that just forward to 
> toolset-specific rules.
> 
> I think we can solve this like this:
> 
> 1. Add type CPP_PCH
> 2. Add a fallback generator for that type that does not produce anything 
> interesting.
> 3. For all supported toolset add generators for CPP_PCH, that have 
> <toolset>xxx in required properties.
> 4. Use calls to generator.override to give toolset-specific generators 
> priority over the fallback generators.
> 
> In the current Boost.Build model, the fallback generator should return 
> something in order not to be considered failed. Fortunately, I think it can 
> just return 
> 
>    [ property-set.empty ]
> 
> which will make Boost.Build think the generator has succeeded, but won't have 
> any effect on anything.

i'll do it asap

> Also, I forgot why we need 'cast'? I think it's a bit ugly, what problem does 
> it solve?

pch generator interfere with mc toolset:

    MC -> RC -> OBJ
      \-> H -> PCH -> OBJ