From: David Abrahams (dave_at_[hidden])
Date: 2006-05-05 15:09:02
Vladimir Prus <ghost_at_[hidden]> writes:
> On Friday 21 April 2006 18:15, David Abrahams wrote:
>> Zbynek Winkler <zw-bjam_at_[hidden]> writes:
>> >>If you don't have time to design it all, but have some ideas, please
>> >> speak out. Note, especially, that you don't need to have any deep
>> >> knowledge of V2 *code*, you just need to think about the best user
>> >> interface, so it's a good way to affect V2 without learning jam language
>> >> ;-)
>> > :-)
>> > For (1) I think the generator should be given a chance to decide which
>> > properties make sense for the target being built. Thus generating pdf
>> > from tex wouldn't have to end up in debug directory but a C compiler
>> > would respect it.
>> In BBv1 we had the concept of "relevant" properties. Properties that
>> weren't relevant to the toolset would never show up in the target
>> path. We should be doing the same thing with generators in BBv2. If
>> we're not, why not?
> Because it's not implemented, and scheduled for M12:
> I'm just wondering what other approaches for shortening targets paths are
Whatever they may be, we should start with that one. It's highly
effective, and it's likely to be orthogonal to any other idea we come
There are only a few possibilities I can think of:
1. Represent composite properties whenever possible to avoid
representing their constituents explicitly. I think we're
already doing that.
2. Stop representing the values for binary non-implicit features
with default values. IOW, just "threading" rather tahn
3. Register and use abbreviations for common features. IOW, "mt"
rather than "threading"
-- Dave Abrahams Boost Consulting www.boost-consulting.com
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