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. > > Daz > > >> >> Cheers, >> Peter >> >> >> >> >> -- >> View this message in context: >> http://gradle.1045684.n5.nabble.com/command-line-order-and-parallel-build-tp5711162p5711189.html >> Sent from the gradle-dev mailing list archive at Nabble.com. >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > > > -- > Darrell (Daz) DeBoer > Principal Engineer, Gradleware > http://www.gradleware.com > Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, > CA: http://www.gradlesummit.com > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Luke Daley Principal Engineer, Gradleware http://gradleware.com Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
