On 17/01/2013, at 11:20 PM, Luke Daley wrote:
> What's the relationship between a component and a “functional source set”?
It varies. The model would be something like this:
- A component is physically represented using one or more packagings.
- A packaging is built from one or more input build items.
- A packaging is a build item.
- A (functional) source set is a build item.
So, for a Java library, it'd look like this:
production source set ---> production class packaging ---> production jar
packaging
Add in some test fixtures:
production class packaging ---+
+---> test fixture class packaging ---> test
fixture jar packaging
test fixture source set ------+
Maybe add some source and docs:
+---> api doc packaging
production source set --+
+---> source packaging
The production jar, test fixture jar, api doc and source packagings are all
aspects of the Java library component.
For a C library, it might look like this:
production source set --+--> windows 32bit shared lib packaging
+--> windows 32bit static lib packaging
+--> linux 64bit shared lib packaging
+--> …
Each of these platform-specific packagings, along with the API docs and source
packagings, are all aspects of the component.
So far, a given source set ends up in a single component. But that doesn't
necessarily need to be the case:
For an Android app, the graph might look like this:
production source set --------------+
'lite' product flavour source set --+--> 'lite release' class packaging -->
'lite release' apk packaging
'release' build type source set ----+
production source set --------------+
'lite' product flavour source set --+--> 'lite debug' class packaging --> 'lite
debug' apk packaging
'debug' build type source set ------+
production source set --------------+
'pro' product flavour source set --+--> 'pro debug' class packaging --> 'pro
debug' apk packaging
'debug' build type source set ------+
Here, there are 2 components: the 'lite' and the 'pro' edition of the app (*).
Each component has 2 packagings: a 'release' and a 'debug' packaging. A given
source set can end up in multiple packagings for multiple components, and a
given component is built from multiple source sets.
>
> What if the definition of a component included the source? Or maybe, a
> certain kind of “buildable” component.
I think pretty much every component is buildable in some way, but not
necessarily buildable by Gradle. It makes sense to have some kind of link back
to the source that the component is assembled from. We might add 'source
packaging' as a first-class concept, where one way to package up a component is
to simply provide an archive containing its source files. For some components -
e.g. a C header-file only library or a javascript library - this may be the
only way that the component is packaged.
>
> 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
>
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
