From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-07-10 11:58:00
David Abrahams wrote:
> > I think it can be a free feature, but an ordinary one.
> Did you mean "can't" here?
> > to target without requirements. Then, how can we propagate the first
> > and not propagate the second?
> I wouldn't want either one propagated.
Good. We agree so far. But doen't it mean you can't you a free feature to
specify python's arity? It just won't affect most of the targets. Or am I
> > > Answering my own question: one possibility might be that users write
> > > specific command-line option handling code in Jamfiles:
> > >
> > > --boost-python-max-arity=XXXX
> > With ordinary feature you'd have
> > boost-python-max-arity=XXXX
> > in the command line.
> As I said before, I wasn't thinking of adding new build features for this
> purpose, though that might be a good choice in this case. I guess this
> would be a composite feature containing just the appropriate <define>
> Hmm, it's not so simple: we don't have a way to propagate values
> from a composite property to its components, yet.
I don't understand this part, sorry.
> This feature wouldn't in
> practice affect link-compatibility. Furthermore, I'd want a separate way to
> keep it out of subvariant paths.
Yes, that's reasonable.
> That is to say, building with different optimization levels should create
> new subvariants, whereas building with different settings of
> boost-python-max-arity should not.
Okay. I've an impression this should be something different from both
ordinary and free features. Don't know what exactly, yet.
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