Re: [jamboost] Disallow free property in build request

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

David Abrahams wrote:

> > > 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?
>
> If <python-arity>7 is propagated to the dependencies, then there will be
> two values of <python-arity>. That can't work.

Yes, you're right. Seems like we'd need non-free properties which don't 
generate subvariants.

> > 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.
>
> Not exactly: I was proposing to simply use an existing free feature,
> <define> to achieve that effect. You were the one who suggested that arity
> should be a feature at all. Once we do that, I think it should be a
> non-free non-propagated non-subvariant link-compatible feature.

But... in our discussion we've agreed that neither free properties in target 
requirements nor free properties in build request can be propagated. How will 
<define> setting will take effect?

> > Can we return for a moment to my original question: is it reasonable to
> > disallow free non-propagated properties in build request?
>
> I guess I return to my original answer: not unless we provide some other
> way to handle cases like BOOST_PYTHON_MAX_ARITY.
> Hmm, OK, that value can be specified in target requirements -- there's no
> need to do that on the command-line.
>
> Still, I can easily imagine a user wanting to "just build this thing
> with -DFOOBAR=BAZ" (non-propagated). If we take your proposal, it's
> basically saying that some feature must be specially designed by the
> Jamfile writer to handle any such configuration.

So, you're saying that free properties in build request should propagated to 
to *all* targets? I don't like this idea, actually. As for user wanting 
"-DFOOBAR=BAZ" in command line: well, allow that and you can't guaranteed 
correct build anymore. User touches some files and rebuild *some* targets 
with different defines. You can't catch that. 

I now really feel that free properties in command line is a bad thing. 

> > 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 don't think so.

Because it can have only one value per target? In which case we'd have to 
somehow refine the definition of free property. For me, it's some minor 
aspect of the build process. It affects something but the person running 
build system should be isolated from them. For example, I'd say that build 
request specifying include paths is rather strange. 

I think we can just add a kind of free property which can have only one 
value. This is an alternative to non-free features without subvariant dir, 
and I think it's better. Let's keep ordinary features simple: they 
significally affect build and generate subvariant dir.

> > > > 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)
>
> Which is what I want in this case.

You want them to be propagated?

> > , or
> > you expand them before generating individual targets. Why generators will
>
> be
>
> > more havyweight then classes corresponding to features?
>
> I think generator matching and definition is a relatively complicated
> process. If someone is defining a project which just needs a macro for
> configuration, I don't want them to have to understand everything about
> generators in order to support it.

There's yet another approach. We can convert <python-arity> into define when 
passing properties to the actual generating rule (the one which constructs 
jam's build action). So, there will be some special handling of features 
prior to construction. Your idea about assining classes to features can be 
used there.

This is not going to be very heavyweight. 

> > and don't understand the place of such properties in the complete
> > system.
>
> Let's keep talking.

Okay.

- Volodya