ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Solofnenko <>
Subject Re: Enforcing "depends" order for 3rd-party targets?
Date Tue, 19 Aug 2008 15:54:21 GMT
Sometimes it is difficult to understand the order even if there are no 
impossibilities. "^" - intersection, "-" - substruction, "->" ordering, 
";" - ordering in dependencies. I tried incrementally processing the 
ordering rules, but that did not work - implicit dependencies can be 
reversed by other rules:

G:     A;B     // all b* should be execute after all a*
A:     a1, a2
B:     b1, b2
a1:    b1; a2    // now b1 should be executed before a2

So the ordering rules should have priorities - the rules for targets 
that are in dependencies of other rules should have higher priority, but 
what about targets that are not related:

G:     G1, G2
G1:    A;B     // all b* should be execute after all a*
A:     a1, a2
B:     b1, b2
G2:    b1; a2    // now b1 should be executed before a2

Okay, since b1 and a2 are in dependencies in A and B, than this rule 
should have a priority. Now:

G:     G1, G2
G1:    a1;B     // all b* should be execute after all a*
A:     a1, a2
B:     b1, b2
G2:    b1; A    // now b1 should be executed before a2

A person still can deduct the order  {a1, b1} -> {a2, b2, A, B, G1, G2, 
G}, but the "priority" notion does not work there - both rules are 
symmetric. Interestingly, the order between a1 and b1 is not determined 
- both rules negated each other. At the end I thought that instead of 
priorities, a "voting" system should be used, the order votes are 
counted and then the order is determined, but I feel, the "voting" 
system will not work - at the end it will evolve into votes with 
priorities and it will be thrown away.

Instead there should be something like a logical deduction system that 
works with sets of targets, but at this moment my mind is not bend 
enough to solve it. Another possibility is to use a math to assign each 
target a value and then minimize some function that depends on order 
rules to have the rules better satisfied. Or maybe forget about it and 
support only simple cases and reject all others.

- Alexey.

Dominique Devienne wrote:
> On Mon, Aug 18, 2008 at 5:51 PM, Alexey Solofnenko
>> {depends(clean) ^ depends(build)} -> {depends(clean) - (depends(clean) ^
>> depends(build))} -> {depends(build) - (depends(clean) ^ depends(build))}"
>> This effectively means that all targets in {depends(clean) - (depends(clean)
>> ^ depends(build))} should depend on all targets in {depends(clean) ^
>> depends(build)}.... And it is assuming that none of the other targets impose
>> other ordering rules. However it is an important feature that is required
>> for a real parallel executor. If you know a solution, please let me know.
> You've lost me Alexey. Could you explain your ^, -, -> notations some
> more please? I can appreciate that mixing ordered and unordered
> dependencies could result in impossibilities, but these could be
> detected and flag as errors, no? --DD
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Alexey N. Solofnenko <>
Pleasant Hill, CA (GMT-8 usually)

View raw message