From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-05-03 05:39:16
David Abrahams wrote:
> > ** Implement notion of compatible and incompatible property sets **
> > - Rountine apply-requirements ( build-request : requirements )
> "Rountine" is not a word I know. Possibly you meant "Routine"? Anyway,
> what's wrong with "rule"?
> > Returns the property set that should be used for building
> > a target with 'requirements' given the 'build-request'.
> > Return empty string when 'requirements' cannot be satisfied.
> > (Should some explanation be returned in this case?)
> Yes, definitely. Otherwise, it will be hard for people to understand
> why targets are skipped.
> > - Rountine compose-requirements ( requirements1 : requirements2 )
> > Returns a requirements set which is satisfied iff both
> > 'requirements1' and 'requirements2' are satisfied. Returns
> > an empty string otherwise.
> > (Seems like does exactly the same as
> > apply-requirements. However, it's better to have another
> > name, to avoid confusion)
> I think it's not the same. I think the build request is a "soft"
> property set. Some elements of the request may be ignored or modified
> according to the target requirements. However, I wonder about the need
> for compose-requirements. Why not just dump the requirements together
> as in $(requirements1) $(requirements2)?
I'm now thinking that compose-requirements should really be the same as
apply-requrements. I believe that we should treat inherited requirements in
the same "soft" manner. For example, if parent has <optimization>off
and current project require <optimization>space, we just ignore
<optimization>off. If parent has <rtti>on and current project require
<rtti>off, we just refuse to accept such requirements. This is the semantics
I suggest in
Anybody has any objections?
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