Re: [jamboost] Disallow free property in build request

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

- Volodya