Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-07-11 07:24:53

David Abrahams wrote:
> ----- 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
> 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.
> 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.

They can specify that in their own requirements, can't they?

It's funny how our discussion evolves: we've started with my declaring arity
should not be a free feature and your stating that it should be, and now we
have exactly opposite opinions.

Can we return for a moment to my original question: is it reasonable to
disallow free non-propagated properties in build request?

Also, not sure that having only a single value per target can be used to
distinguish targets. Will "warning level" be free feature, for example? I
guess it should not generate subvariant directory and is just a minor detail
of the build process.

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

Hmm.. either you expand that property before calling generate the first
project target (and your free <define> properties won't be propagates), or
you expand them before generating individual targets. Why generators will be
more havyweight then classes corresponding to features?

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

Not yet. I still don't understand where your composite property will expand
to defines, and don't understand the place of such properties in the complete

- Volodya


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