Re: [jamboost] Disallow free property in build request

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

- Volodya