Re: [jamboost] Disallow free property in build request

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-07-15 08:13:31

David Abrahams wrote:
> ----- Original Message -----
> From: "Vladimir Prus" <ghost_at_[hidden]>
>
> > 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.
>
> That was my feeling. Personally, I'd rather we look through the attributes
> carefully for the first 15 or 20 features we define and see which sets
> emerge, than try to group them at this stage.

Ok, that's reasonable. But later, grouping commonly used sets is a must for 
reasonable UI.

> > 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.
>
> We can handle that at the level of error/sanity checking when the feature
> is declared. Right now the feature code is very simple because it just has
> to look at a pile of attributes and ask "is A in $(attributes)"? Adding
> attributes that are more than just on/off bits will complicate things. I
> don't want feature attributes to turn into property sets themselves, if
> possible

I understand what you mean and it makes sense to me. Okay, let's try to 
settle on one-bit attributes.

> > 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.
>
> Sure we can:
>
> no-subvariant (warnings)
> main-target (defines)
>
> ...and if you really want to, we can issue an error if they're used in the
> wrong combination.

Hmm.... that will do it. I'm not very fond of the idea of multidimentional 
space where a lot of cominations are meaningless, but let's try it.
And certainly, I *want* an error message when somebody tries to declare 
features with "subvariant-dir" and "main-target" attributes!

> > > 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.
>
> Not that one. A default value for a multi-valued feature makes sense. If
> there is no value specified, the value is X. Simple. (simple is better than
> complicated)

Can you give an example where this is needed? 

It appears that I prefer to disallow cases not explicitly needed, so that we 
can enable them later, while you have exactly opposite approach. Don't know 
which is best, althought yours seems easier to implement.

> > > 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.
>
> I just don't think we're ready to design attribute groups yet. Partly
> that's because your terms "principal", "minor", and especially "trait"
> don't resonate for me. Maybe if you listed all our existing (v1) features
> and a few anticipated v2 features, and tried to categorize them this way it
> would become clearer to me...

Can we try splitting "principal -> ... " axis into
"subvariant-dir" and "main-target-dir" attributes and proceed with this 
arrangement?

- Volodya