Re: [Boost-build] [rfc] Shorter build paths.

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-12-18 10:45:08

Vladimir Prus wrote:
> On Sunday 17 December 2006 02:59, Rene Rivera wrote:
> 
>> The path generation algorithm would, given the build properties, go 
>> something like:
>>
>> 1. start with an empty build path
>> 2. for each registered feature path:
>>     a. if the feature path requirements match a subset of the build 
>> properties, remove those properties and add the path to the build path
>> 3. trim the redundant properties
> 
> What properties are "redundant"?

I'm not sure precisely what they are... I was just using the same term 
you have on the comments of property.as-path which says "trim redundancy".

>> 4. split the properties into incidental and non-incidental
>> 5. translate the incidental properties onto the front of the build path
>> 6. translate the non-incidental properties onto the back of the build path
> 
> Ehm, I don't think we add incidental properties to the path at all, at the moment.

I meant "implicit" vs. "non-implicit". Sorry for the confusion.

> I think that's right, but in either case, this is independent from shortening of build paths.
> 
>> 7. generate the final build path from the components
>>
>> The effect is that the path is compressed based on the defined shorthand 
>> paths plus any additional specific build properties. The one requirement 
>>   would be that the feature paths would need to be unique. But that is 
>> something easily checked and an error generated. 
> 
> So basically, if user maps
> 
> 	<variant>release <threading>multi       to    release-mt
> 
> then if he tries to map
> 
> 	<variant>release <link>static <threading>multi       to    release-static-mt
> 
> he'll get the error? We might need to act better, but such a restriction would be fine for
> the first version.

No I meant that if they map:

   <variant>release <threading>multi --> release-mt
   <variant>release <link>static <threading>multi --> release-mt

It would error as the resolution ends up being ambiguous. Your example 
above we can handle by preferring larger replacements first. Where 
larger means the longer list of requirements.

> The only concern I have is with several projects used together. If one Jamroot specifies
> some set of rules for path shortening, I think those rules should not affect targets
> under other Jamroots -- because those Jamroots might have their own rules set.
> 
> So, I suggest that those path-shortening rules be defined in Jamfile and apply only
> to that Jamfile and children thereof. What do you think about this?

I see your point but I'm trying to see what we loose by *only* having 
that in jamfiles. I thought that their would be some benefit from having 
some standard shorthands, i.e. defined in tools/builtin.jam for example, 
that would provide the benefit of shorter paths for everyone out of the box.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo