Re: [jamboost] Disallow free property in build request

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-07-15 04:30:19

David Abrahams wrote:

> > I now think that motivation is reasonable. (And that decision
> > allows to leave existing code almost intact). However, I'd much
> > appreciate if
> > you could put express your motivation in good English so that we can
> > include it in docs.
>
> We have to decide the meanings of various feature attributes first. Remind
> me once that's done.

Okay.

> > 3) If a target is both top-level target, and used by other top-level
> > target, it is build with the properties as-if it were simply top-level 
> > target. 
> >
> > Is this proposal ok?
>
> Fine. Can we call these top-level targets "directly requested" instead? I
> think it's much more memnonic than "top-level".

Agree.

> > > Did you miss the post where I wrote:
> >
> > I did not have in cache when writing the last message, sorry.
> > So what do we have about properties now.
> > I suggest these axes:
>
> My intention was that every feature attribute was an orthogonal axis.
>
> > 1. principal -> minor -> trait
>
> This sounds like a high-level classification of feature attribute sets into
> named groups... is it neccessary/useful?

We certainly can have every feature attribute as a separate axis, but I'm 
afraid that would make it overly complex: imagine that to define a new 
feature you have to recall definitions of 10 different attributes. We can 
define attribute sets, of course, so that "minor" would be interpred as
synonym for non-propagated, non-subvariant-dir-generating feature.

For this particular axis, "propageted" attribute can't be set artitrary. For 
example, "minor" feature can't be propagated, IMO. Even if I agree that using 
"define" in command line is OK, propagating them to dependencies is way too 
troublesome. 

Moreover, there are in fact three different option w.r.t subvariant dir:
- generate them
- use the same handling as for free properties now (dir includes main 
target's name)
- don't use any subvariant dir.
I don't think we can fold this axis into two feature attributes.

> > Principal features are for most important things like variant,
> > optimization
> > or threading. They are propagated and generate subvariant dir.
> >
> > Minor features are for fine-tuning build. Defines fall there. They don't
> > generate subvariant build but are handled like free features are now: if
> > the set of minor features for some target is not equal to project
> > requirements,
> > that target location is augmented with its main target name.
> > Minor features are not propagated (like free features now)
> >
> > Trait features have no effects on build process at all. They are for
> > warning
> > control etc. I think we can safely have them always propagated.
>
> Sounds OK, though I don't like the name "trait". I'd rather call them
> "incidental" or something which indicates their lack of impact.

Every name is OK for me. 

> > 2. single-valued -> multi-valued
> >
> > The first kind can have only one value per target and that value can be
>
> from
>
> > finite set. The second kind can have several values per target and they
>
> are
>
> > arbitrary.
> >
> > (I see not use for features with several possible values per target with
> > values from finite set. And the same about features with arbitrary values
> > which can be set only once per targets).
>
> OK.
>
> > 3. optional and symmetric are just two flags which apply only to single
> > values features.
>
> Why? Wouldn't it be simpler just to leave every feature attribute as an
> orthogonal axis to all others?

How can you define the default value for a multi-valued feature. It's OK to 
have mostly orthogonal axises, but some combination will be meaningless.

> > The proposal above is just a slightly refined version of the current (V1)
> > semantics, so it's easy to do what you want.
>
> I'm not sure that I see the value of grouping the attributes in this way.
> One of the problems I had in v1 was that I kept discovering features which
> needed to work "mostly like" some category of feature, "except for..."
>
> Part of my motivation for separating all the attributes as I have done in
> v2 was to avoid having prescribed combinations prevent us from doing what
> we want.

As I understand, the question is mostly about 
principal -> minor -> trait axis. As I've said before we have three different 
subvariant to dir mapping, so I think this axis should be left as is. We can 
introduce orthogonal "propagated" attribute, but how will be accomodate the 
fact that principal features are propagated by default?.

I'd hate to write:

feature variant : : principal propagated ;
feature define : minor non-propagated ;

So, we either should have fixed value for the "propageted" attribute or 
predefined attribute groups, IMO.

- Volodya