On 11/02/2013, at 7:31 PM, Marcin Erdmann <[email protected]> wrote:
> On 29/01/13 07:44, Adam Murdoch wrote:
>> Implementation-wise, I would think about busting up building the task graph
>> into 2 steps:
>>
>> 1. Build the task graph proper, with a node for each task in the graph and
>> edges to represent the various types of dependencies.
>> 2. Once the graph is built, calculate the execution plan:
>> - Take each node that has no incoming edges, sort them and then traverse
>> each in turn.
>> - To traverse a node
>> - Take each soft dependency, sort them and traverse each in turn.
>> - Take each hard dependency, sort them and traverse each in turn.
>>
>>
> I think I have already found an issue with the solution I proposed in my
> previous email.
>
> Currently it is valid to add a new task to the execution graph from within
> gradle.taskGraph.whenReady{}
This is news to me. I always thought things were locked by this point, but I am
far from familiar with this part of the codebase.
> which means that we should probably indeed build a graph and determine
> executionPlan every single time TaskExecutionPlan.addToTaskGraph() is called
> not to break that contract. Looks like I'll need to work on building the
> graph in the end.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
