Boost logo

Boost-Build :

Subject: Re: [Boost-build] intermediate directory control
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-05-13 09:30:11


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

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

In Christ,
Steven Watanabe


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