Boost logo

Boost-Build :

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

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



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at