Re: [jamboost] [BBv2] Order sensitive features - testing some ideas

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-10-26 01:51:09

Hi Alexey

> I did some experiments with order sensitive features. Take a look on the
> attached .diff files for reference. Note that this is just a concept not
> the final patch. :)
>
> So the problem is that presently all properties are sorted and so there
> is no way to control their order. In some cases this is not acceptable,
> for example when Platform SDK is used together with MSVC.
>
> The solution is to join all order-sensitive properties using "&&" syntax
> before they get sorted:
>
> <include>b <include>a -> <include>b&&a
>
> All property sets are created by the 'property-set.add' rule so the
> joining logic can be added here.

Well, that would require lots of profiling. Previous, I've tried to make 
<include> order-sensitive, with some loss of performance as the result. It 
would be best either have some occurences of <include> order-sensitive, not 
all, or introduce another feature. But profiling is indeed needed.

> The second problem is merging different property sets. They can come
> from different places: it can be properties of a target, project
> properties, usage properties, etc. I didn't find any better way to deal
> with it but to add new properties in front of existing ones.
>
> pset1 = [ property-set.create <include>b <include>a ] ;
> pset2 = [ property-set.create <include>z <include>y ] ;
>
> # The result - '<include>z&&y&&b&&a'
> pset1 = [ $(pset1).add $(pset2) ] ;
>
> This works in case of include directories but in reality the order will
> depend on the order of processing corresponding property sets.

Speaking about PSDK, am I right that you "only" need to add PSDK includes 
before any MSVC include paths? Where are MSVC include paths are specified?

Ah, btw, this order dependency issue is not unique, we have the same messy 
thing with static libraries on Linux. See unix.jam, rules 'order-libraries' 
and 'set-library-order' and the util/order.jam file. Maybe, it would be more 
reliable to specify order dependencies for <include> statements, and reorder 
them right before building targets. This will be more reliable.

> Open questions:
>
> 1. What is the order of precedence of different property sets a user may
> define? We have:
>
> - project properties;
> - target properties;
> - project usage requirements;
> - target usage requirements;
> - parent project properties;
> - anything else?

There's no "precedence". Free properties from all above sources are merged 
together in no specific order.

> 2. Should different kind properties (include and sources for instance)
> have different precedence order?

Can you clarify?

> 3. Do we need to control order of values after two property sets get
> merged (i.e. new properties are added in front or to the end of existing)?

Maybe a mechanism to explicitly control the order of two specific properties 
is more general and useful.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2