From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-11-23 10:36:00
On Wednesday 23 November 2005 11:57, Reece Dunn wrote:
> Reece Dunn wrote:
> > Q: Given a property set $(ps), how do I remove a property if I don't
> > know it's value.
> > e.g.
> > local newps = property-set.remove "<pch-header>" : $(ps) ;
> I have worked out howe to do this:
The standard way is this:
local newps = [ property-set.create
[ property.change [ $(ps).raw ] : <pch-header> ] ] ;
The "change" rule is used to change the value of feature to some other value,
but with empty value it just removes everything.
> and am using it here...
> # Run the PCH generator, passing in the source file for the PCH.
> local r =
> [ generator.run $(project) $(name) :
> <pch-source>$(sources) # mypch.cpp
> ] : $(sources)
> ] ;
> But although the code works, it is in the wrong place! This is because
> lib a : pch_a ... ;
> lib b : pch_b a ... ;
> we have:
> PCH(A) --> LIB(A) -\
> PCH(B) --> LIB(B)
> where LIB(B) inherits both PCH(A) and PCH(B) properties. :(
Yes, usage requirements are propagated infinitely. Is the above real-world
case? Can you explain this to me? Should pch-related usage requirements
*always* apply only to direct depenents? Are there any other corner cases?
I think it's possible to make pch-related feature "propagated to direct
> NOTE: I have attached the --debug-generators for the above scenario if
> someone wants to help find a solution.
> The alternative that Alexey suggested of having:
> lib a : ... : <pch>pch_a ;
> lib b : a ... : <pch>pch_b ;
> does not (I think) allow you to add a generator for the PCH file to
> generate the *.pch file.
What do you mean by "add a generator for the PCH file"? I think the biggest
problem with this approach (assuming PCH rule is modified to add no usage
requirements) is extracting header name from the target. I honestly don't
know about right solution.
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