Property utilities

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 
http://groups.yahoo.com/group/jamboost/message/819

Anybody has any objections?

- Volodya