-----Original Message-----
From: Nicolas Lalevée [mailto:[email protected]]
Sent: Tuesday, August 23, 2011 5:32 AM
To: Ant Developers List
Subject: Re: Opinions on a possible optimization enhancement to Ivy buildlist
to support a form of incremental build
Le 18 août 2011 à 21:21, Richard Mauri a écrit :
> I would like to get a discussion started around an enhancement I am
> considering to contribute to ivy buildlist.
>
> I think it would be a valuable addition, and would like to hear from
> others before contributing a formal patch/contribution.
>
> The goal of this contribution is to support a form of incremental build
> where given a set of changed components the buildlist would return a
> short list of components that must be visited for rebuild.
>
> Consider a hierarchical component directory structure (the project) and
> a master build.xml with subdirectories containing ant/ivy components.
>
> Parent
> |
> |-A
> |-B
> |-C
> |-D
> |-E
>
> Consider a dependency relationship like (A depends on B etc.)
>
> A
> /\
> B C
> \ /
> D
> |
> E
>
> Today, ivy buildlist can be used by this parent build to ultimately
> determine the ordered build sequence (in this case starting from most
> independent).
>
> E D B C A
>
> Now, given that the toplevel build has available to it a set of
> components have been touched (Change-Set) ,
> I'd like to constrain the list returned by ivy buildlist so that only
> those components in the change set PLUS
> the components that directly depend on the change set is returned (the
> rebuild-list).
>
> The reason the direct dependencies are included is to catch API contract
> violations that must be caught during the rebuild.
>
> Change-Set: {E,C}
>
> Rebuild-List: E D C A
>
> I assert that subsequent subant iteration over Rebuild-List would be
> more optimal than iterating over the entire project
> (imagine 100's of comps in the project).
>
> The enhancement to build list would be to add an attribute that
> represents the Change-Set and enhance the DFS DAG traversal reporting to
> return only the Change-Set and the components that depend directly on
> Change-set
>
> Thoughts?
I find it quite weird that transitive dependencies are not taken into account.
In your example, what if B was using some of E as by transitivity it's got into
its libraries. B should be recompiled then, no ?
If I understand correctly the problematic and if the transitivity is to be
taken into account, I think a simple modification to ivybuildlist would be
needed : make it support several roots. A such improvement would definitively
makes sense.
Nicolas
-------------
Thanks for the response Nicolas
You're right, transitivity has to be accounted for.
The example of B calling an inherited method e1() defined on E, would demand
that B be recompiled when E.e1 signature changed like to e1(int i).
Regarding the support for several roots: I see now that there is support for
multiple roots or leaves.
I think I'm interested in the multiple leave feature of ivybuildlist. Given my
leaves/known changed modules {E,C}
return the modules that directly or indirectly! Depend on these leaves.
So no enhancement needed. Right!
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
