$include_dir="/home/hyper-archives/boost-build/include"; include("$include_dir/msg-header.inc") ?>
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-10-11 04:25:42
Vladimir Prus wrote:
> 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?
The example/pch builds fine for me too, on msvc and gcc.
What I referred to was the example in the docs, which will not work with gcc
because of the constraints on the target / pch header file naming. Try
modifying example/pch to specify a different name for the pch target:
---
import pch ;
cpp-pch pch2
: # sources
include/pch.hpp
: # requirements
<include>include
;
explicit pch2 ;
# exe
##########################################################################
exe hello_world
: # sources
pch2
source/hello_world.cpp
: # requirements
<include>include
: # default build
: # usage requirements
;
---
Running bjam under gcc now outputs:
---
error: in Jamfile</path/to/bbv2/example/pch>: pch target name `pch2' should
be the same as the base name of header file `include/pch.hpp'
---
I don't know if this is an issue with the gcc compiler itself, or with the
gcc toolset pch support implementation.
[snip]
>
> 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.
Yes. I just figured that the better part of the users are not using pch,
therefore building with pch off (even explicitly) should not add "pch-off"
to the build path.
>>
>> 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.
>
[snip some code adding <include> to usage-requirements]
>
> 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?
I'll have to get back to that. IIRC I only saw the problem when the target
using pch was a subproject, and I invoked the build from the project root
directory.
/ Johan