From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-11-23 11:02:52
Vladimir Prus wrote:
>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
>but with empty value it just removes everything.
> > with:
> > 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?
This would be a real-world case. Especially for complicated projects that
have many libraries all dependant on each other, all (or most) using PCH
>I think it's possible to make pch-related feature "propagated to direct
That would solve this problem. Do you know how to do this?
> > 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 meant that with this alternative approach, it is not clear how the
msvc.compile.pch rule+action (and the pch-generator) can be invoked to
produce 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.
The propagate to direct descendants only will solve this issue and would be
the 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