On 23/04/2013, at 10:20 PM, Adam Murdoch <adam.murd...@gradleware.com> wrote:
> > On 18/04/2013, at 11:39 PM, Luke Daley <luke.da...@gradleware.com> wrote: > >> >> On 15/03/2013, at 1:38 AM, Adam Murdoch <adam.murd...@gradleware.com> wrote: >> >>> Hi, >>> >>> There's now a first cut of the new source set DSL in master. Right now, it >>> pretty much just mirrors the old structure: a project has a set of >>> 'functional source sets', and each functional source set has a single >>> 'language source set' for each supported language. The next step is to >>> introduce some flexibility in this model, so that you can use it to model >>> other structures. In particular, we want to be able to group source in more >>> interesting ways: >>> >>> - Group multiple source sets of a given language to be compiled together. >>> For example, when building the 'release' variant of my Android application, >>> I want to take the 'main' java source and the 'release' java source and >>> compile them together as a single batch. >>> - Group multiple source sets of different languages to be compiled >>> together. For example, I want to take my 'main' java source and my 'main' >>> groovy source and compile them together as a single (logical) batch. >>> - Group multiple source sets together to form some logical thing. For >>> example, I want to take my 'main' java source and 'main' resource and >>> 'main' groovy source and bundle them together in a 'main' source set that I >>> can pass around as a single thing and add as input to various things or >>> publish or whatever. >>> >>> When we add a source set to a binary, we need to be able to turn it into >>> the language specific views in order to compile it (or whatever it is we >>> need to do with it). For example, for Java source we need to know the Java >>> language level that the source conforms to and the compile dependencies >>> that the source has, plus some general stuff like the character encoding >>> that the source files use. >>> >>> Ideally, this language specific view is read-only (and even better if it is >>> immutable) and somewhat more general than the view you would use to >>> configure the source sets. >>> >>> The current plan is to have language-independent composite source sets and >>> language-specific (and strongly typed) source sets. The language source >>> sets are the 'atomic' groups of source, which you can combine in whichever >>> way you like by creating a composite source set and adding the appropriate >>> source sets to it. A composite source set would accept both language and >>> composite source sets. These source sets would all be configurable. >>> >>> In addition to this, we would have a separate set of strongly typed >>> interfaces that define the language specific stuff you need to consume the >>> source. You can ask a source set to turn itself into one of these views (it >>> may just return `this`). The aim here is to keep separate the consumption >>> of source set from how they are defined and configured, and so allow many >>> different ways that source sets can be defined and built, but a consistent >>> way to plug them in as inputs to something else. >>> >>> Things get a bit tricky when source sets need to be combined into a single >>> set, as the strategy for merging the language-specific stuff is, itself, >>> language-specific. There are a few approaches we could take: >>> >>> 1. Composite source sets know how to combine language source sets. They >>> would need help from the language specific plugins for this, possibly by a >>> language plugin registering a converter of some kind. >>> >>> 2. Composite source sets are just dumb collections of source sets. When you >>> add a composite source set to a binary, it is equivalent to adding each of >>> its children separately. A language plugin may make available a language >>> source set implementation that can combine other language source sets of >>> the same type, and you need to wire these up yourself. >>> >>> 3. Composite source sets are just dumb collections of source sets as for >>> #2, and all language source sets can contain other language source set of >>> the same type. >>> >>> At this stage, I think we'll probably go with #1, as it means that the >>> aggregation is completely the source set's business (though the source set >>> may ask some plugins for help), and nothing to do with the consumer. >>> >>> Regardless, for any of these options, to add support for a new language you >>> need to provide a language specific source set, plus some strategy for >>> merging the language source sets, plus some rules for what to do when the >>> language source sets are added to a binary. >> >> Why do we need to try and do this dynamically? How dynamic really is this >> situation? Only certain different language source sets are combinable. Also, >> there may be different strategies for composition. For example, compilation >> options that are only relevant when joint compiling. > > I was actually talking about composing source sets of the same language for > joint compilation: how do we express this in the DSL, how do we merge the > various language-specific meta-data I'm not sure there is a global strategy for merging. Some things will be cumulative (e.g. classpath) others will be based on a minimum or maximum (e.g. language level) and others might have more complex relationships (e.g. individual compile flags). > how do we expose this to consumers, etc? > > But yes, you're right that there's only certain combinations of different > languages that we're interested in composing into a single logical thing, and > those combinations are relatively static. They have proven to be very static to date. > We're more interested here in extensibility, so that a given language does > not need to know about all the other languages it can be jointly compiled > with. Why would it need to know? Why wouldn't whoever is driving the joint compile process provide the model of the joint compile? In other words, If there is joint Groovy/Java compile, I don't see why the Java "infrastructure" would need to know anything about this. > It's not really that tricky to make this work. A plugin simply needs to tell > us that it can either generate Java stubs from its source or that it can > parse (but not compile) Java source, then we can coordinate the rest. Doesn't seem like where to invest to me. I don't think we (or at least me personally) are going to get much further without considering concrete use cases. -- 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
