Spec comments

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-23 06:57:36

Context for the list: some time ago Ali wrote a proposal for improved V2 
architecture. After some off-list discussion we did not decide anything,
except that we should keep all discussions on list. So I'm posting an attempt 
on analysis the spec. The spec itself can be found at

http://boost.sf.net/boost-build2/architecture.txt
http://boost.sf.net/boost-build2/architecture.pdf

but note that it's not yet finished.

First, here's my analysis of the way we process properties currently. We start 
with main-target.generate call. 

1. Inside main target
1) apply-default-build is called
2) property-adjuster is called
3) select-alternatives is called which selects an instance of
basic-target, which 'generate' method is called

2. Inside basic-target
1. refined-properties is called, which
1. Calls 'property-set.refine'
2. Calls 'property-set.evaluate-conditionals'
3. Calls 'property-set.run-actions'
2. All dependency properties are found and generated.
3. All sources are generated
4. Usage requirements propagated from dependencies in steps
2 and 3 are added to the property set used for building
5. The 'construct' method is called
6. Usage requirements that should be retuned are determined
1. Conditionals in usage requirements are evaluated
2. Dependency properties in usage requirements are generated
3. Usage requirements from 2) are added

In Ali's proposal:

- 1.2 and 1.3 are omitted
- 2.1 is basically retained
- 2.2 and 2.3 are handled in one step, because sources are considered as
property <source>
- 2.4 is handled implicitly by 'addProperty' method called everywhere
- 2.6 is omitted.

My comments:

0. I don't really like the idea that conditional properties are evaluated in 
context accumulated after evaluation of previous conditional properties.
IOW, meaning of conditional properties depends on order. On Jabber, Dave said
there was some use case which asked for order-dependent semantic, but could 
not remember that use case.

1. The 'property-adjuster' is present in current code for a reason -- to make 
'direct_request_test.py' work. I agree that it's somewhat complex, but I 
don't know a simpler solution.

2. select-alternatives is just omitted and no concrete replacement is 
proposed. In some list discussion, it was said that it's still will be 
necessary to select only one element from a group --- which makes me wonder 
if 'select-alternatives' is still needed.

3. The 'addProperty' method in the proposal adds properties to 
this->"usage-requirements" --- but it cannot do that. Main target can be 
generated with different properties and different usage requirements can be 
generated. I suspect that fixing this problem will make usage requirements 
processing similiar to the current one.

4. The current code does something complex with sources. It groups all virtual 
target generated from the same main target dependency together. This allows 
to issue a warning about unused source only if no virtual target from a 
single main target was consumed.

5. How initial value of 'usage-requirements' is converted into value that is 
returned is not specificed. In particular, it's not stated what is done with 
conditional properties and dependency properties.

6. It was suggested long ago that library sources are treated intelligently. 
I.e. library which is source of another statically linked library would 
automatically become usage requirement. Is it possible with the proposed 
algorithm? How?

- Volodya