I agree with Luke. The guarantees have to be the same whether or not `--parallel` is used. If necessary, a new command line syntax/switch could be introduced that doesn't take ordering of task names into account (though I'm not sure it's needed). Changing the guarantees of the current syntax is not an option in my mind. Maybe build types could offer ways to control parallel execution constraints.
Cheers, Peter Luke Daley-2 wrote > On 11/04/2013, at 11:36 PM, Szczepan Faber < > szczepan.faber@ > > wrote: > >> Hey guys, >> >> Today, I had a long chat with PeterN about our current strategy for >> command line order in a parallel build. Consider this: >> >> gradle taskA taskB --parallel >> >> 1. We can let taskA graph and taskB graph execute in parallel. That's how >> Gradle 1.5 works and it feels pretty natural to me. It breaks certain >> 'clean build' scenarios (e.g. >> http://forums.gradle.org/gradle/topics/problem_with_clean_in_parallel_mode) >> 2. We can let taskA graph execute in parallel first. Then we let the >> taskB graph execute in parallel. This approach can be considered more >> consistent with the single threaded execution. >> >> What's the right way? > > Given what we have right now, it has to be that these can't be run in > parallel (option 2). That is, 'taskB' must-run-after 'taskA'. My reasoning > for this is that this is the only execution order control mechanism > outside of dependencies, so this seems the safest option. > > If I run: ./gradlew build release > > I expect that things are built and tested before any releasing occurs. > Release tasks rarely have hard dependencies on test tasks. > > It's far less clear to me one there is richer information available. If > there are all kinds of mustRunBefore etc. relationships defined between > tasks, then you could make an argument that Gradle should parallelise as > much as possible and just respect the relationships as defined. My gut > feel though is that task order on the command line should _still_ imply a > must-run-after relationship though as it's more predictable and easier to > understand. > > -- > 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 -- View this message in context: http://gradle.1045684.n5.nabble.com/command-line-order-and-parallel-build-tp5711162p5711165.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
