Boost logo

Boost-Build :

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.
>>this e-mail does not fit to the mailing list, so i've sent it directly.
>>see attached 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

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