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
> > be adjusted by changing a #define. In theory this creates ODR
> > but in practice each individual user of the library can set this
> > 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.
> After all, we'd have no explicitly "propagated" features otherwise.
> build request is
> gcc <define>BAR ;
> I think it's correct to say that applying requirements mean conceptually
> we use the build request
> gcc <define>BAR <define>FOO
> to target without requirements. Then, how can we propagate the first
> 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
> 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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk