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

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:
> 
>    bin/libs/filesystem/build/vc8/debug/static-mt
>    bin/libs/filesystem/build/vc8/debug/dynamic-mt
>    bin/libs/filesystem/build/vc8/release/static-mt
>    bin/libs/filesystem/build/vc8/release/dynamic-mt

I think this approach is similar to what we do with 'composite' features. For example,
        
        <variant>release

is actually a shorthand for

        <optimization>full ..............

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?

Thanks,
Volodya