Re: [jamboost] Disallow free property in build request

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-07-10 11:58:00

David Abrahams wrote:

> > I think it can be a free feature, but an ordinary one.
>
> ^^^
> Did you mean "can't" here?

Yes.

> > to target without requirements. Then, how can we propagate the first
>
> define
>
> > and not propagate the second?
>
> I wouldn't want either one propagated.

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?

> > > Answering my own question: one possibility might be that users write
> > > specific command-line option handling code in Jamfiles:
> > >
> > > --boost-python-max-arity=XXXX
> >
> > With ordinary feature you'd have
> >
> > boost-python-max-arity=XXXX
> >
> > in the command line.
>
> 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.

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

- Volodya