Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-10-09 14:08:25

Johan Nilsson wrote:

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

The example/pch builds fine for me, on msvc. Do you have a specific
error with that?

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

The default value of a feature is never shown in path, no matter how requested,
unless the feature is marked 'symmetric'. Switching the order won't quite help
-- you'll either get pch-off or pch-on in path, depending on how you compile.

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

Probably; I don't know what a good syntax would be, however.

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

Strange. When I modify the example/pch project as follows:

ghost_at_wind:~/Work/Boost/boost-svn/tools/build/v2/example/pch$ svn diff
Index: Jamroot
--- Jamroot (revision 39621)
+++ Jamroot (working copy)
@@ -13,6 +13,9 @@
   : # requirements
+ : # default-build
+ : # usage requirements
+ <include>foobar
 explicit pch ;

And run "bjam -n pch=off" (on gcc/linux), I do see -Ifoobar on the
command line. Do you have a small example where this is not

- Volodya

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