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
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
- 2.4 is handled implicitly by 'addProperty' method called everywhere
- 2.6 is omitted.
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
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