From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-12-18 07:12:51
On Sunday 17 December 2006 02:59, Rene Rivera wrote:
> So here's my latest idea...
> * Shortening what is a regular longer build combination:
> feature.path static-mt :
> <link>static <threading>multi ;
> feature.path dynamic-mt :
> <link>dynamic <threading>multi ;
> feature.path vc8 :
> <toolset>msvc-8.0 ;
> Which might produce the following paths:
I think this approach is similar to what we do with 'composite' features. For example,
is actually a shorthand for
and when generating target paths we notice that <variant>release includes <optimization>full,
so <optimization>full is not added to the target paths.
So, I think your approach should generally work.
> 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"?
> 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 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.
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?
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