Re: [jamboost] Disallow free property in build request

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-15 08:32:29

From: "Vladimir Prus" <ghost_at_[hidden]>

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

Nope.

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

In general, I agree with you especially when the language is as liberal as
Jam's. However, features won't be defined often and it's OK to ask people
to exercise some care in this case. A bad experience with building in the
wrong arbitrary limitations is leading me to be a little more liberal, and
a desire to keep the implementation straightforward (so we can debug it)
helps too.

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

Sure, that sounds fine to me. Just to keep people from having to type
subvariant-dir all over the place, though, I'd rather that was the default,
so we have

no-subvariant
main-target-dir

Oh, wait: they're orthogonal! Imagine property <foo>bar is in the build of
target baz:

no-subvariant:0 1
\
main-target-dir \------------------------------------------
0 | .../bin/foo-bar/ .../bin/
|
1 | .../bin/baz/foo-bar/ .../bin/baz/

I see no problem here.

-Dave