Thanks!
I'm doing something like this specifically for the XcodePlugin that I've
created.
@Override
void apply(Project project) {
if (project.hasProperty("android")) {
XcodeExtension e = project.extensions.create('xcode',
XcodeExtension)
.... other magic ....
project.afterEvaluate {
BaseExtension android =
project.getExtensions().getByName("android")
android.applicationVariants.all { variant ->
//println variant.class.toString()
Task compileXcodeTask = project.tasks.create
("compile${variant.name.capitalize()}Xcode", XcodeBuildTask)
.... other magic ...
Task compileNdkTask =
project.tasks.findByName("compile${variant.name.capitalize()}Ndk")
compileNdkTask.dependsOn compileXcodeTask
}
}
}
}
I don't want the new native building tools in gradle (new or old). I'm
building my own that support calling 3rd party build systems for native
(namely Xcode but also ninja and cmake) that we have trained to work with
our middleware NDK replacement at Apportable.
My current problem is that these build systems do not creat a root folder
like ndk-build does with everything in neat CPU specific folders. They
output each lib in a d ifferent folder. Our old build system supported this
concept. The jniLibs/ABIFilter system is a bit aggravating taking only a
root set of folders. I want to be able to specify FILES for a specific CPU
arch not in a specific direction with specific subdirectories. The way the
AndroidBuilder and Packager work this is all hardcoded all the way down to
the core and it's frustrating because right now I'm using copy tasks to
make temp folder with the layout that jniLib root and it's useless time and
cycles that are not necessary. I would love if the source set for that
jniLibs was changed around this to allow for specific files for specific
arcs in a map instead of giving only a set of root folders.
On Tuesday, September 9, 2014 7:04:57 PM UTC-7, Xavier Ducrohet wrote:
>
> We will indeed provide both native support inside "regular" android
> projects (apps or libs) and the ability to build pure native projects.
>
> The trick is packaging the output of the native project in a way that's
> compatible with the android project that consumes it. Right now the only
> way to do it is to generate an aar with all supported ABIs which is not
> great if you're doing a build/deploy/test on a particular ABI.
> The new native stuff that's coming in Gradle should allow you have the
> native project publish all its artifacts separately (per-ABI but also
> build-type debug vs release) and to have the app project consume which
> artifact is needed by the variant you're building. It's not there yet
> though.
>
>
> On Tue, Sep 9, 2014 at 4:33 PM, Zac Bowling <[email protected]
> <javascript:>> wrote:
>
>> 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]
>> <javascript:>> 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]
>> <javascript:>> 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] <javascript:>.
>>> 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] <javascript:>.
>> 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] <javascript:>.
>> 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 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.
