Re: [jamboost] Disallow free property in build request

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-10 12:13:45

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

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

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

-Dave