From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-11 07:04:48
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
> Yea, I understand this.... back to my question. I think I wasn't thinking
> very good yesterday. As I understand, the arity should apply to all the
> using Boost.Python. For example:
> exe everything : a.cpp lib1 lib2 : <python-arity>7 ;
> Here, <python-arity>7 should apply to lib1 and lib2. It also should apply
> lib1 and lib2 when it is not in requirements, but in the build request.
> just make <python-arity> free *and* propagated feature! According to my
> proposal, it will be allowed in build request.
Hmm, no. In general, lib1 and lib2 should be allowed to have their own idea
of what maximum arity they need. And it really shouldn't be a free feature
because you can only have one single value per target.
> > How do you define a property which generates values for other
> > In other words:
> > * we don't want to write custom support for boost-python-max-arity into
> > each toolset.
> > * therefore boost-python-max-arity=xxx must be translated somehow into
> > <define>BOOST_PYTHON_MAX_ARITY=xxx.
> > * We don't have a way to define features which do that, yet. Current
> > composite features just get expanded into a set of pre-defined
> Oh, I now see what you mean. I don't think it's a good idea, though.
> request expansion, where <define> will be added, happens immediately
> loading projects. And <define> is simple free property, so it won't be
> proparated. Maybe, a specialized generator is better used to add the
> appropriate <define> for each target?
Oof, that's awfully heavyweight. I guess I'd prefer just to turn features
into classes, so each one could expand in its own way.
> > Probably just adding a new "no-subvariant" feature attribute would be
> > enough to handle the subvariant part.
> Yes. But now I'm not sure we need it.
Have I changed your mind 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