Re: [Boost-build] intermediate directory control

Subject: Re: [Boost-build] intermediate directory control
From: Vladimir Prus (ghost_at_[hidden])
Date: 2012-05-13 10:19:24

On 13/05/12 17:30, Steven Watanabe wrote:
> AMDG
>
> On 05/12/2012 11:19 PM, Vladimir Prus wrote:
>> On 13/05/12 05:29, Steven Watanabe wrote:
>>> On 05/12/2012 06:07 PM, George Georgiev wrote:
>>>> Is it possible I to supply my own hash function for the --hash option?
>>>> MD5 is OK for the CI, but I wish it is a little bit more human
>>>> friendly when I need to browse intermediate directory.
>>>>
>>>
>>> It isn't possible now, but it sounds like a great
>>> idea to me.  This issue comes up pretty often here.
>>>
>>> How does something like this look:
>>>
>>> project : requirements<location-property-path>@compute-property-path ;
>>>
>>> rule compute-property-path ( property-set )
>>> {
>>>       local p = [ $(property-set).as-path ] ;
>>>       # change p
>>>       return $(p) ;
>>> }
>>>
>>> This would also allow you to include/exclude
>>> any properties you want.
>>>
>>> Volodya?  If this seems reasonable I'll
>>> start implementing it.  It should be
>>> pretty straightforward.  (Obviously
>>> the property could use a better name.
>>> location-property-path is just the
>>> first thing that came to mind)
>>
>> Steven,
>>
>> this makes sense to me. I am somewhat worried about adding the number of
>> solutions though. Maybe,
>> we should declare --abbraviate-paths as deprecated when you implement
>> your proposal? Or maybe,
>> we should eventually extend '--hash' to generate some kind of manifest
>> file explaining where
>> to find which build products?
>>
>
> What about:
>
> --abbreviate-paths is a deprecated synonym for
> location-property-path=property-set.abbreviate-paths
> and --hash is a deprecated synonym for
> location-property-path=property-set.hash-paths.
> (This is way too long.  I'll come up with better names.)

That will work.

> To make this work, we need the ability to define
> a feature that can hold any single value, but not
> multiple values.  There are other features
> that would benefit from this as well, like<tag>.

Interesting idea. I was thinking that we need to fix "--" vs. "" mess on the command line,
by introducing special features that can have only one value throughout all projects, and
then make --foo and foo= be equal on command line where 'foo' is such feature. I suppose
that location-property-path should also be consistently set across entire build?

But yeah, making 'can have any string as value' and 'can have multiple values' be separate
flags on feature is generally reasonable.

- Volodya