On 25/06/2013, at 5:25 PM, kelemen <attila.keleme...@gmail.com> wrote:
> 2013/6/25 Adam Murdoch [via Gradle] <[hidden email]> > > On 24/06/2013, at 5:26 AM, kelemen <[hidden email]> wrote: > >> Hi, >> >> As asked by Luke Daley, I'm sending my notes on lazy configuration to the >> dev list. The idea of lazy task confiuration is roughly described here: >> http://forums.gradle.org/gradle/topics/allow_tasks_to_be_configured_just_before_execution >> >> I will summarize: >> >> As I know, you are already working on lazy configuration. I would like to >> have some notes and reguests. >> >> 1. I believe that my proposed lazy task configuration can solve many >> practical problems and is a simple concept: Easy to comprehend. In short, >> lazy task configuration is a configuration block which is executed just >> before the task is executed. >> 2. I understand, that you want something more generic. If I can have a word >> on it, I would like if you don't make something like >> publications { >> // lazy block >> } >> >> This is because making some of the configuration block lazy while others >> being eager (they must remain eager until Gradle 2 for backward >> compatibilty), is inconsistent and very confusing. So rather, I'd prefer a >> syntax like this: >> >> publications lazy { >> // lazy block >> } > > The goal is to eventually make all configuration lazy. So, we don't really > want a DSL that has the keyword 'lazy' in it - it's just noise once > everything is lazy. We also, as Luke pointed out, want a DSL that describes > the what (there are some publications) rather than the how (configure these > publications now, configure these publications later). This is important to > allow Gradle to skip configuration that isn't required, as a declarative DSL > doesn't express anything about when. The when is inferred and can be 'never'. > > I think there are 3 broad approaches we can take here: > > 1. Mix the delayed and the eager together. I know most people don't agree > with me, but I think with some good diagnostics this can actually work well. > Certainly don't take how it currently works as any kind of indication of the > comprehensibly or otherwise of this approach, as we've only started on > implementation and the approach is reliant on good diagnostics. > > It's not that mixing them is bad but it should be easy to distinguish between > eager and lazy configuration. Such as a keyword (if not for lazy, then eager). > > 2. Introduce a new section in the build script to group all the delayed > configuration. Some things will only be available through delayed > configuration, some things will be available through both eager and delayed > configuration. Over time, we would reduce the set of things available through > eager configuration via deprecation. > > I'm not sure what you actually mean in grouping configurations but somehow I > feel that it might be too much noise. Just something like a big fat block around everything: project { // this is all delayed … source { main { cpp { ... } } } publications { somePub { … } } } Everything inside the block is 'DSL 2.0' and everything outside the block is 'DSL 1.0'. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
