From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-07-21 00:09:02
David Abrahams wrote:
> > Consider:
> > exe a : a.cpp :
> > <variant>debug:<optimization>speed
> > <optimization>off:<define>USE_SLOW_BUT_TESTED_ALGORITHM
> > ;
> > Now, someone just calls "bjam" and "a" will be built with default
> > properties: "<variant>debug <optimization>off". Requirements are
> > evaluated and the result is that <optimization>speed is used and
> > <define>USE_SLOW_BUT_TESTED_ALGORITHM is added.
> > And that's confusing! I'd expect the target to be build either with
> > <optimization>speed or <optimization>off and <define> to appear only in
> > second case. But the target is build with <optimization>off and <define>.
> > IOW, one conditional requirements changes property used as condition for
> > another.
> This is just one example of why Ali and I wanted to define
> conditional properties to be evaluated in order.
Alas, if you write
exe a : a.cpp :
(i.e) swapping the conditional properties, and evaluate them in order, you
*still* get <define>USE_SLOW_BUT_TESTED_ALGORITHM and <optimization>speed in
final build properties, which I found confusing.
> It's really easy to
> imagine other cases. For example,
> on platforms X,Y, and Z use toolset A
> and on toolset A define FOOBAR
Looks reasonable, though I'm not sure extra implementation complexity is
> > I think the simplest solution is to declare that in conditional
> > property, part after ":" can be only free or incidental
> Why would you want to impose that limitation?
To avoid surprising behaviour in the simplest possible way.
> > and that free/incidental features cannot be present before
> > ":". Opinions? Anybody using non-free conditional properties?
> I don't know; this sounds terribly limiting to me.
As they say in XP, "you aren't gonna need it".
Nobody said that this limination will have any effect on existing projects.
Further, now, how non-free features behave in conditional requirements is not
specified and is quite confusing. We either have to fix this (which would
take time), or impose the limitation. We can always lift it later.
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