On 09/04/2013, at 7:52 AM, Adam Murdoch <[email protected]> wrote:
> > On 09/04/2013, at 3:05 AM, Luke Daley <[email protected]> wrote: > >> >> On 30/03/2013, at 11:57 PM, Adam Murdoch <[email protected]> wrote: >> >>> Hi, >>> >>> With the new source sets DSL, you can define multiple source sets of >>> various types and multiple binaries and attach source sets as inputs to >>> binaries. Each source set can be used as source input to multiple binaries, >>> and each binary can accept multiple source sets as input. >>> >>> Each source set added to a binary is compiled separately from the other >>> inputs. The idea here is this allows you to compose a binary from source >>> sets compiled in various different ways. To jointly compile all source for >>> a binary, you first compose the source into a single source set and then >>> attach that to the binary. So, for each (source-set, binary) edge in the >>> graph, there is a compile task, and we need a naming scheme for these. >> >> This is a little hard for me to visualise for some reason. Can you give a >> DSL example? > > Here's an example where I produce a `free` and a `paid-for` variant of my > application. The free variant is built by jointly compiling the main source > and the free source. The paid variant is built by jointly compiling the main > source and paid source: > > source { > main { … } > free { … } > paid { … } > freeVariant { // a composite of the main and free source > include source.main.java > include source.free.java > } > paidVariant { // a composite of the main and paid source > include source.main.java > include source.paid.java > } > } > > binaries { > jvm { > free { > source source.freeVariant.java > } > paid { > source source.paidVariant.java > } > } > } > > > For this graph, my `free` binary has a single incoming edge (the combined > free source) and my `paid` binary similarly has a single incoming edge. I > need a task to compile the combined free source for the free binary and a > task to compile the combined paid source for the paid binary. So we'd end up with: * compileFreeVariantForFree * compilePaidVariantForPaid (assuming we've only got the elements explicitly noted above) > > Here's another example graph where I produce Groovy 1.8 and 2.0 variants of > my library. I have physically separated the API and implementation into > separate source sets: > > source { > api { … } > impl { … } > } > > binaries { > jvm { > groovy18 { > source source.api.groovy > source source.impl.groovy > } > groovy20 { > source source.api.groovy > source source.impl.groovy > } > } > } > > For this graph, each of the binaries has two incoming edges - the api source > and the impl source. I need 4 compile tasks for this graph. Named: * compileApiForGroovy18 * compileImplForGroovy18 * compileApiForGroovy20 * compileImplForGroovy20 -- 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
