Re: [Boost-build] [pch] gcc woes

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 @@
     include/pch.hpp
   : # requirements
     <include>include
+  : # 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
working?

- Volodya