Boost logo

Boost-Build :

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,

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?


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at