On 15/04/2013, at 7:02 PM, Luke Daley <luke.da...@gradleware.com> wrote:
> > On 14/04/2013, at 2:51 AM, Daz DeBoer <darrell.deb...@gradleware.com> wrote: > >> On 13 April 2013 17:11, Peter Niederwieser <pnied...@gmail.com> wrote: >>> Daz DeBoer-2 wrote >>>> The problem is that this equivalence doesn't translate to the parallel >>>> world. I guess we don't currently have a nice way to describe the >>>> 'contract' that you're expecting to be honoured >>> >>> I'm not sure if we are on the same page already. What I'm saying is that we >>> should change the behavior of `--parallel` to honor the contract I >>> mentioned. How we do that is secondary (for now). >> >> While I agree this makes sense for: >> "gradle --parallel clean build " >> >> it's not so clear that it works for: >> "gradle --parallel :a:build :b:build" >> Do you really want to wait for 'a' to finish building before starting >> to build 'b'? > > It's more important that `clean build` does the right thing than it is that > `a:build b:build` is as fast as possible. So, without other mechanisms then > it has to work this way for my money. > > Given that we are starting to add the capability to be very explicit about > task orderings though it is indeed not that simple. > >> So I'm not sure about making this an explicit contract. I'm not 100% >> against, but I don't think it's a given either. >> I think we first need to define exactly what the contract means, ie: >> "gradle clean build" constructs an anonymous build-type with >> parameters "clean, build" (where build-type is a well-defined >> construct). > > I'm not sure what anonymous build types would give you. Every Gradle > invocation is effectively an "anonymous build type" in terms of what we have > been describing as build types. > > > The options as I seem them are: > > 1. task order at invocation time implies a temporary should run after > relationship > 2. task order at invocation time implies no relationship between tasks and > the necessary relationships must be described elsewhere > > > To me #2 is definitely better as the more information we have about the task > graph in a mineable way the more interesting things we can do with this > information in other contexts. The problem for me though is that we might be > a ways away from having the capability to do #2. This means we have to live > with the current unsafe behaviour until that time. Given that parallel > execution is an incubating feature, I guess living with the current unsafe > behaviour is not so bad. This pretty much sums up my thoughts as well. With must-run-after, we can pretty much express what we need for the command line: `clean` really must run before `build`. There's no should there. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
