Re: [jamboost] Disallow free property in build request

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-15 07:58:19

----- 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.

> 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

> 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.

> > 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)

> > 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...

-Dave