On 18/02/2013, at 10:16 AM, Marcin Erdmann wrote: > On 17/02/13 22:36, Adam Murdoch wrote: >> >> On 12/02/2013, at 5:56 AM, Marcin Erdmann 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've finally managed to get the stuff that was preventing me from working >>> on that out of the door and I'm looking into this again. >>> >>> Buildinng a task graph seems to be a bit of an overkill to me for this >>> feature as we can get away without it for now. There are two main problems >>> I see with building the graph: >>> - we would need to have three phases instead of the two you are mentioning >>> - first build the graph with only 'hard' dependencies, then go through all >>> nodes and add 'soft' dependencies (soft/always runs after dependencies can >>> only be added when the nodes of the graph are known as a 'soft' dependency >>> only kicks in if the task we should run after is in the graph) and only >>> then perform a toposort >> >> Not necessarily. You can add the nodes for the soft dependencies, and mark >> the node as 'not required'. When a hard dependency is added for a node, the >> node is marked as 'required'. When building the plan, you skip those nodes >> that are not required. > > That's a good point. I have this three phase implementation almost ready but > I will rework it a bit to include your suggestion. I should have a full > version ready for a review by midweek. >
Excellent. Looking forward to it. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
