Boost logo

Boost-Build :

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-10-09 03:33:29


Vladimir Prus wrote:
> Johan Nilsson wrote:
>
>> Vladimir Prus wrote:
>>> On Friday 05 October 2007 10:25:03 Johan Nilsson wrote:

[snip]

>>
>> Also, it seems like the base name of the pch header needs to be
>> exactly the same as the pch target name. Does the provided example
>> (in the docs) really work?
>
> I believe it was tested on msvc when added; I should be able to test
> myself today or tomorrow.

Thanks. Let us know how it goes.

>
>>>> Also - is it possible to disable pch using conditional
>>>> requirements, making the pch rule effectively returning a "null"
>>>> target?
>>>
>>> The <pch>off feature will have that effect.
>>
>> Thanks. However, adding <toolset>gcc:<pch>off to my root project
>> properties caused everything to rebuild as /pch-off/ was added to the
>> target paths. Not much to do about it I guess, but annoying
>> nevertheless.
>
> Well, I guess that, assuming compiler has no bugs, PCH should not
> change
> the generated code, and therefore need not be represented in path.
> Does changing
>
> # control precompiled header (PCH) generation
> feature.feature pch :
> on
> off
> : propagated
> ;
>
> to
>
> # control precompiled header (PCH) generation
> feature.feature pch :
> on
> off
> : propagated incidental
> ;
>
> in pch.jam fixes this annoyance?

I guess it fixes the immediate problem, but I can't tell how safe it is.
Need to think about it.

What is the general path generation policy; does it add default options to
path when they are explicitly requested - perhaps the order of "off" and
"on" could simply be reversed?

>
>> Is there possibly a way to obtain the effect of the imagined
>> conditional requirement
>> "<toolset>gcc,<toolset-version-below>4.2.0:<pch>off" without
>> resorting to indirect conditional requirements?
>
> No.

Thought so (leading question). This could be a generally useful addition to
Boost.Build.

>
>> One final point: Inside the pch target definition, I also setup the
>> path to the pch header as an <include> requirement as I have
>> multiple levels of source directories within the project. As a
>> result of this, when turning off pch, the source files fails to
>> compile (they no longer find the actual pch header file).
>>
>> Do you have any suggestions for how to handle the above in a generic,
>> clean way?
>
> Add the same include as usage requirement on the target?

If pch is off the usage requirement will not be propagated, but the first
line in the source file(s) will still include the statement (e.g.):

#include "mypch.h"

This leads to compilation errors.

/ Johan


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk