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
> > Not that one. A default value for a multi-valued feature makes sense.
> > there is no value specified, the value is X. Simple. (simple is better
> > complicated)
> Can you give an example where this is needed?
> It appears that I prefer to disallow cases not explicitly needed, so that
> can enable them later, while you have exactly opposite approach. Don't
> 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)
> > 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)
> > and a few anticipated v2 features, and tried to categorize them this
> > would become clearer to me...
> Can we try splitting "principal -> ... " axis into
> "subvariant-dir" and "main-target-dir" attributes and proceed with this
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
Oh, wait: they're orthogonal! Imagine property <foo>bar is in the build of
0 | .../bin/foo-bar/ .../bin/
1 | .../bin/baz/foo-bar/ .../bin/baz/
I see no problem here.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk