From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-07-11 04:27:20
David Abrahams wrote:
> ----- Original Message -----
> From: "Vladimir Prus" <ghost_at_[hidden]>
> > 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
> > missing something?
> The macro only affects how many overloads of various functions are
> generated by the preprocessor library in some of Boost.Python's headers. In
> other words, it doesn't affect anything in the Boost.Python DLL -- it just
> makes higher arity support available to clients of the library. So you can
> set it to a different value when compiling each extension module without
> rebuilding the common DLL.
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 code
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 to
lib1 and lib2 when it is not in requirements, but in the build request. So:
just make <python-arity> free *and* propagated feature! According to my
proposal, it will be allowed in build request.
> > > As I said before, I wasn't thinking of adding new build features for
> > > purpose, though that might be a good choice in this case. I guess this
> > > would be a composite feature containing just the appropriate <define>
> > > property?
> > Maybe.
> > > 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.
> How do you define a property which generates values for other properties?
> 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
> * 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 components.
Oh, I now see what you mean. I don't think it's a good idea, though. Build
request expansion, where <define> will be added, happens immediately after
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?
> > > 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
> > > 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.
> 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.
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