What's the relationship between a component and a “functional source set”?
What if the definition of a component included the source? Or maybe, a certain kind of “buildable” component. On 17/01/2013, at 1:10 AM, Adam Murdoch <[email protected]> wrote: > Another question is how to group source sets and packagings. > > For source sets, we currently use two approaches: > > - For Java, Scala, Groovy, ANTRL and resources, we use the functional source > sets, adding the source to `sourceSets.${function}.${language}`. > - For C++, we use language specific source sets, adding the source to > `cpp.sourceSets.${function}.source` and > `cpp.sourceSets.${function}.exportedHeaders`. > > I'd like to come up with a consistent pattern here, which can allow arbitrary > groupings of source files by language and by function. I can see three > options. For all these options, assume that all source sets are composable to > some degree, so, for example, you can add a given Java source set to another > Java source set, or you can add a given Java source set to a composite source > set. > > 1. Java plugin style, where the primary grouping is functional: > `sourceSets.${function}.${language}`: > > sourceSets { > main { > cpp { srcDirs = '…' } > cppHeaders { srcDirs = '…' } > javaScript { srcDirs = '…' } > } > } > > 2. C++ plugin style, where the primary grouping is by language: > `${language}.sourceSets.${function}` > > java { > sourceSets { > main { srcDirs = '…' } > } > } > groovy { > sourceSets { > main { srcDirs = '…' } > } > } > resources { > sourceSet { > main { srcDirs = '…' } > } > } > javaScript { > sourceSets { > main { srcDirs = '…' } > } > } > > 3. Both, where defining `sourceSets.${function}.${language}` also defines > `${language}.sourceSets.${function}` and vice versa. > > 4. A polymorphic container of source sets. You use whatever groupings you > like, and can add language specific or composite source sets to this > container. The opinionated language plugins would continue to group by > function and add a `main` and `test` composite source set. > > sourceSets { > main(CompositeSourceSet) { // possibly the default type > java { srcDirs = '…' } > cpp { srcDirs = '…' } > resources { srcDirs = '…' } > } > test(GroovySourceSet) { > srcDirs = '...' > } > } > > Thoughts? Other options? > > On 16/01/2013, at 5:06 PM, Adam Murdoch wrote: > >> Hi, >> >> To better support building Android apps (and other things), we want to >> rework the jvm language plugins so that they can handle building multiple >> outputs from a given set of source files. >> >> I've made a bit of a start on a spec here, but's pretty rough: >> https://github.com/gradle/gradle/blob/master/design-docs/building-multiple-outputs-from-jvm-languages.md >> >> I need some suggestions for terminology: >> >> 1. A term for the things that Gradle builds. With this work, plus >> publications, components, reports and distributions work that is happening, >> we're starting to model more of the things that Gradle can build. It feels >> like we should have a term for this. So far we've been calling these things >> 'things' and sometimes 'outputs'. I kind of like the term 'build item' from >> abuild. >> >> 2. A term for a thing that runs on a JVM. This is the focus of the spec >> above. The spec calls these things a 'packaging', but this doesn't really >> work that well. Note that this isn't the logical thing - we're calling them >> 'components' - but the physical thing. Initially, there are 2 types of this >> thing - a class directory packaging and a JAR packaging. If we come up with >> a good term for 'things' in #1 above, we could just shove 'jvm' in front of >> it as a name for these things (e.g. 'jvm build item'). >> >> 3. A term for a set of source of a specific language, that forms the input >> to a compilation step. This is different to what we call 'source set' at the >> moment - that's a logical grouping of source. The spec calls these things a >> 'language source set'. >> >> 4. A term for a logical set of source. Currently we call these a 'source >> set'. The spec calls these things a 'functional source set'. >> >> Suggestions? >> >> -- >> Adam Murdoch >> Gradle Co-founder >> http://www.gradle.org >> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting >> http://www.gradleware.com >> > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
