Re: [jamboost] Disallow free property in build request

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-10 11:42:28

From: "Vladimir Prus" <ghost_at_[hidden]>

> David Abrahams wrote:
> > I can't agree. For example, the maximum arity supported by Boost.Python
can
> > be adjusted by changing a #define. In theory this creates ODR
violations,
> > but in practice each individual user of the library can set this
#define
> > differenty for his own use. How would we support that?
>
> I think it can be a free feature, but an ordinary one.
^^^
Did you mean "can't" here?

I wasn't thinking of reserving a build feature for this purpose, since it's
just a preprocessor define.

> I still can't
> understand how can we reasonable allow free features in build reqest.
>
> exe a.exe : a.cpp biglibrary : <define>FOO ;
>
> I hope you agree that <define>FOO should not be propagated to biglibrary.

Yes.

> After all, we'd have no explicitly "propagated" features otherwise.
Suppose
> build request is
>
> gcc <define>BAR ;
>
> I think it's correct to say that applying requirements mean conceptually
that
> we use the build request
>
> gcc <define>BAR <define>FOO

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.

> > 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? Hmm, it's not so simple: we don't have a way to propagate values
from a composite property to its components, yet. This feature wouldn't in
practice affect link-compatibility. Furthermore, I'd want a separate way to
keep it out of subvariant paths.

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.

-Dave