That is really close to what I'm looking for. I need to detect if it's a library project or application project but I can go that direction. The tasks I need to hook as dependencies on are consistently named so I can branch off that.
I'm debating if it makes sense to actually move all the native build aspects to a new dependent project instead of trying to make it work in the same android app plugin owned project like the NDK plugin does it. I could have my native building plugin work on it's own project and output AAR format libraries instead in it's own assemble task like the library plugin. Then get dependent compiling working instead with it instead of trying to mix into the Android plugin own project. It feels more natural doing that maybe. (Use the artifact API possibly?) The native libraries do have some JNI hooks into the main application code but really I would love separating the concerns between native building needs and Java/Android app/lib building into different projects conceptually. That way I can rebuild the native bits separately from the final app. Like Library targets but without worrying about Java or other android needs that don't concern native (like AIDL, Renderscript, etc tasks). It almost seems like the NDK plugin should go this same direction of moving NDK building to another plugin outside the AppPlugin/LibraryPlugin level IMHO. Maybe a NativePlugin in addition to AppPlugin and LibraryPlugin. I'm may be completely wrong but it feels more natural for the NDK integration to do that. I'm not using the NDK plugin myself (old or new) in my plugin since it's redoing things that we have better solutions too in our build system with product for supporting multiple platforms, but the same challenges exist in the NDK builder for end users I'm sure (I've got 3 build systems in my head and trying to make them play together elegantly in a maintainable way and convert metaphors and concepts across each which makes this a bit more confusing so I might just be crazy). Thanks! Zac On Sep 9, 2014, at 2:51 PM, Xavier Ducrohet <[email protected]> wrote: > Why do you want to be notified when tasks are being created instead of doing > it after? If you do: > > android.applicationVariants.all { variant -> > } > > you will effectively be called as soon as each variant is created and get > access to all its tasks. Is this not enough? > > > On Tue, Sep 9, 2014 at 2:26 PM, Zac Bowling <[email protected]> wrote: > Hey guys! > > I want extend the DSL for variants/flavors and add build tasks that compile > for each variant to build JNI libs using our own build systems for each > variant. > > The way it works inside the plugin is very hardcoded in VariantManager but I > would love to get a callback myself to create my own tasks. What I would love > to do is know the VariantData like it's passed around internally. > > Right now my method is super hacky. I'm running through all the tasks as they > are added and parsing the task names to add dependencies. It's not optimal. > > The source provider/artifact API concept looks like it is my only hook to add > different libs to each variant but it's only for adding additional folders. > That works for me to set directories but doesn't help me on the task side. > > My goal is that I'm building this so you can call arbitrary build tools (like > cmake or xcodebuild) with the current variant info so that custom JNI libs > can be built for each flavor/architecture/configuration. > > Is there is a cute method I can use without hacking or calling private APIs? > > The short term is I could fork and refactor the Android plugin but I don't > want to pull what Amazon did (and hopefully work with their fork maybe) and > be able to work if you apply my plugin after the Android one (sort of where > the new NDK plugin seems to be going). Would you guys be open to pull > requests if I refactor the base plugin to expose a few methods to get > callbacks from the VariantManager when it's creating tasks? > > Thanks!!! > > ~ > Zac Bowling > Engineering - Apportable, Inc > http://apportable.com/ > > > > -- > 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. > > > > -- > Xavier Ducrohet > Android SDK Tech Lead > Google Inc. > http://developer.android.com | http://tools.android.com > > Please do not send me questions directly. Thanks! > > -- > You received this message because you are subscribed to a topic in the Google > Groups "adt-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/adt-dev/dGDBoJdNLtQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. -- 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.
