Re: [Boost-build] Shortening target paths

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:
>
>   https://zigzag.cs.msu.su/boost.build/ticket/4
>
> 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
       "threading-on."

    3. Register and use abbreviations for common features.  IOW, "mt"
       rather than "threading"

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com