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
