Re: [jamboost] Disallow free property in build request

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-11 09:18:18

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Thursday, July 11, 2002 8:24 AM
Subject: Re: [jamboost] Disallow free property in build request

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

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

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

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

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

> I
> guess it should not generate subvariant directory and is just a minor
detail
> of the build process.

Yes.

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

Which is what I want in this case.

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

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

In the usual place, I think.

> and don't understand the place of such properties in the complete
> system.

Let's keep talking.