Thank you Mark.
What I want is just a way to define buildField values more flexible
choosing the value by flavor / build type.
I want to be able to set those values differently for every combination of
flavor and build type, possibly setting a default if I do not want to
override.
The reason I want this are 3:
1. having to set those value over and over again for each variant is
tedious and create lot of boilerplate code
2. it is not straightforward to me how defaultConfig, variant config and
build type config relate with each other, if I set the same variable as
build config in all of them which is applied? the variant one? the build
one?
3. I don't know how to have 4 different value for the combo free+debug,
free+release, pay+debug, pay+release (to simplify I just used 2 variant and
2 build types as an example)
Your message helped me understand better how gradle works, I still didn't
get it very well.
Now I understand all those setting are in evaluated in a phase that do not
yet have anything to do with the actual compile of a single variant. And
the code they contains is executed regardless of which variant I build.
But I still don't have any idea on how to solve the 3 things I wrote about
above.
Thanks,
Daniele
On Saturday, November 15, 2014 6:49:18 PM UTC+1, Mark Murphy (a Commons
Guy) wrote:
>
> On Sat, Nov 15, 2014, at 12:34, Daniele Segato wrote:
> > Meaning theres no way to do what I want yet?
>
> If by "what I want" you mean "obtain the 'current' flavor", then no,
> there is no way to do what you want, other than by iterating yourself
> over build variants.
>
> The only time there is a "current" anything is inside a task. Tasks are
> things executed when we actually do the build. Stuff like productFlavors
> {} and buildTypes{} are more along the lines of data structures, where
> any Groovy code is executed when the script is read in.
>
> Now, you can certainly define your own tasks, and those tasks can be
> specific per build variant. You can set up those tasks to depend upon
> some other task, and (presumably) you can configure other built-in tasks
> to depend upon yours. Whether you can affect buildConfigField this way
> and accomplish your aims, I cannot say. And how well this will hold up
> over time, as Gradle for Android evolves, I cannot say.
>
> --
> Mark Murphy (a Commons Guy)
> http://commonsware.com | http://github.com/commonsguy
> http://commonsware.com/blog | http://twitter.com/commonsguy
>
> _The Busy Coder's Guide to Android Development_ Version 6.1: Wear?
> There!
>
--
You received this message because you are subscribed to the Google Groups
"adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
