On 28/07/2011, at 10:43 AM, Luke Daley wrote:
> Hi guys,
>
> With the object containers, you cannot currently influence how an object is
> to be created using the DSL eg.
>
> someContainer {
> element1 {
>
> }
>
> element2 {
>
> }
> }
>
> Where element1 and element2 are auto created via the existing mechanism. I'd
> like to add support for the following…
>
> someContainer {
> element1(foo: "bar") {
>
> }
>
> element2(baz: "bat") {
>
> }
> }
>
> The idea being that implementations could use the attributes map to influence
> how elements are auto created. I think that this is a good capability
> generally, but it does make things slightly looser.
I suspect something like this might be useful. For example, you'd be able to
use it to define tasks:
tasks {
mytask(type: SomeType) { ... some config ... }
}
I would really like to move tasks into their own namespace, and this would
allow us to do this.
Building on this, we'd have a consistent DSL for containers of polymorphic
elements, something like:
repositories {
someRepo(type: Ivy) { ... }
someOtherRepo(type: Maven) { .... }
}
>
> For example, what would the default impl do? Would it ignore the properties?
> Would it use them to configure the new element by map? Would it throw
> UnsupportedOperationException.
It would be nice if the factory declared which properties it needs (defaulting
to an empty set), and any extra entries in the map are used to configure the
new element by map. For example:
tasks {
myzip(type: Copy, from: sourceSets.main.output, into: 'someDir)
// same as
myzip(type: Copy) {
from sourceSets.main.output
into 'someDir'
}
}
This approach deals nicely with the case where a property changes from required
at construction time, to optional at construction time. Doesn't help with
changes the other way, though.
Another question is what happens when you use the map approach when the named
object already exists? Fail? Fail only if read-only properties specified in the
map? Fail only if read-only properties specified in the map have different
values to those on the target object?
>
>
> The use case I have in mind is where a “native source set” has many outputs,
> so something _like_:
>
> cpp {
> sourceSets {
> main {
> // config of where source is
> outputs {
> main {
> // configure how this is to be compiled
> }
> debug(parent: main) {
> // add how to compile a debug variant, inheriting all of the main
> settings
A few comments on this dsl:
* Can parent be a mutable property, so you can specify in the configure
closure? Is it really a fundamental property of a variant?
* It feels to me like variants are a top-level concept, and would be defined
elsewhere. This would include things such as how they inherit from each other.
What the above dsl for a source set might instead specify is 'when I am to be
compiled for the debug variant, include -DSOME_DEF in the compiler args'.
* Something such as how to build debug vs non-debug variants is probably more a
concern for the compiler/linker implementations, than the source set dsl. That
is, when I'm driving the dsl to define my executables or libraries, I do not
want to concern myself with how to ask the compiler to build debug versions.
Gradle should just figure this out.
For example, we might use different strategies for building debug/non-debug
variants, based on the compiler and platform we are using. For example, on
linux with gcc, we might compile once with -g to build the debug variant, and
then just copy and strip the resulting binary to build the non-debug variant.
On windows with msvc, we might compile one with /MT to build the non-debug
variant, and compile again with /MTd to build the debug variant.
Variants might also affect publication too, so that on linux we can resolve
against either the debug or non-debug variants of our dependencies, but on
windows we must resolve against only the variant we are building.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
