Re: [jamboost] Build process specification.

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-31 01:36:56

Hi Ali,

Ali, Azarbayejani wrote:
> I like your answers, because that is what I would want...I would want
> <include> properties NOT to be propagated further than the direct
> dependents and of course <library> properties (meaning basically
> "link-to" when used in Usage Requirements) MUST be propagated to
> indirect dependents.

Ok, we're in agreement so far.

> But my point is that I don't like that the semantics of Usage
> Requirements are inconsistent...the propagation of <include> is
> different than the propagation of <library>, but they look the same to
> me. There seems to be no rule that applies in general to properties
> appearing in Usage Requirements.
>
> - You pointed out earlier that the rule "Usage Requirements are
> exactly equivalent to Requirements in each direct dependent" is not
> true.
>
> - The rule "Usage Requirements appear in the Build Properties of
> direct dependents" is not complete.
>
> On the contrary, the semantics of Requirements seems clear. A
> property in Requirements of a Target will appear in the Build
> Properties for that Target.
>
> Do you understand my complaint? 

I'm not yet sure. Consider usage requirements of 

<include>foo/bar <library>a 

The client of main target with such usage requirements will have added to its 
build properties
- <include>foo/bar
- <library>a
- usage requirements of 'a'

The latter will be added because "library" feature is "dependency feature". 
That is the rule which works here. You say:

the propagation of <include> is different than the propagation of
<library>, but they look the same to me

Semantically they are not the same: <library> is dependency feature, while
<include> is not. So, I conjecure you mean that syncactically, they look 
the same? Is that a problem? After all different kinds of features behave 
differently in many contexts. E.g.

exe a : a.cpp : <link>static <define>FOO ;

When it comes to building this target, the <link> and <define> features are 
handled a bit differently, but I don't see there's a problem.

> Is it okay with you, from a design
> and usability standpoint, that the semantics of how properties in
> Usage Requirements apply and propagate to dependents is inconsistent?

I still don't see anything wrong. Yes, <library> and <include> are handled 
differently a little, but they are somewhat different properties. Do you have
some proposal in mind, which can achieve the same <include>-non-propagated and 
<library>-is-propagated semantics and be less inconsistent from your opinion? 
Probably, concrete suggestion will help to understand your point better.

- Volodya