Boost logo

Boost-Build :

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

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

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

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at