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