You should be able have a hybrid environment, but be aware that dependency
management will have significant changes in the near future.
We might support gtest, but probably not in the very short term. Please
file a feature request if you do not want it to get lost. Thanks.
On Friday, July 10, 2015 at 1:14:53 PM UTC-7, Steven Winston wrote:
>
> Hi Raymond,
>
> Thanks for taking the time. cppFlags +=
> "-DVERSION=\"${rootProject.getVersion().toString()}\"".toString() does
> indeed fix the problem. Some of the third party libs we depend upon aren't
> 64bit compatible, so I'll delay the full dive until 64 bit is working.
> I have a question, if I have a hybrid environment (i.e. the build.gradle
> for one of my modules (a library) uses the experimental gradle ndk, is
> there a way that this could work with the rest of the project using the
> more stable 1.3r2? Or does the entire dependency chain have to be one the
> same gradle?)
>
> Also, I did manage to get gtest (unit testing) working in the new
> experimental, it's using a custom task dependency. Are there plans on
> putting an official way of doing gtest in a nicely provided call?
>
> Thanks,
> Steve
>
> On Friday, July 10, 2015 at 8:55:25 AM UTC-7, Raymond Chiu wrote:
>>
>> Hi Steven,
>>
>> I work on the plugin. I made some of the trivial corrections in the
>> documentation and will correct the rest soon. Thanks for pointing them
>> out. I hope to address some of your other concerns
>>
>> "First it's still quite sad that there is no mechanism to use older
>> library builds with pre-existing .mk files. I get around this as I always
>> have by creating own task that calls ndk-build."
>>
>> We are working on it.
>>
>> "cppFlags += " -I" + file('../../../Common').absolutePath
>> will result in compiler errors that the file or directory <path>/Common
>> is not found and it wont compile. However, remove the space prior to the
>> -I flag and it's all good. I had to remove all spaces on front and back of
>> all cflags and do a separate flag per line with cppFlags += <newFlag>"
>>
>> Filed
>> https://code.google.com/p/android/issues/detail?id=179497&thanks=179497
>>
>> "android.buildTypes { } should include isDebuggable = true and
>> isJniDebuggable = true."
>>
>> There are some changes to the DSL that will address this in the next
>> minor release.
>>
>> "I can get gradlew to run the compiler, but the GUI doesn't actually run
>> the ndk build task. If I run the gradle task from the GUI :app:build then
>> it does build the ndk build task but F9 gives me everything but."
>>
>> I will look into this.
>>
>> "For the life of me I couldn't get cppFlags +=
>> "-DVERSION=\"${rootProject.getVersion().toString()}\"" to work. Am I doing
>> something wrong with it?"
>>
>> Is your error "org.codehaus.groovy.runtime.GStringImpl cannot be cast to
>> java.lang.String"? If so, you can workaround it by adding .toString() to
>> the GString for now. i.e. cppFlags +=
>> "-DVERSION=\"${rootProject.getVersion().toString()}\"".toString(). If not,
>> please let me know what error did you get.
>>
>> "Also should note that setting abiFilters has no barring on what will be
>> compiled. The NDK will try to compile all abiFilters no matter what."
>>
>> Known issue: https://code.google.com/p/android/issues/detail?id=177337
>>
>> Thanks again for the feedback!
>>
>> Raymond
>>
>> On Thursday, July 9, 2015 at 6:10:17 PM UTC-7, Steven Winston wrote:
>>>
>>> It's very pleasant to see Google finally release this.
>>>
>>> First it's still quite sad that there is no mechanism to use older
>>> library builds with pre-existing .mk files. I get around this as I always
>>> have by creating own task that calls ndk-build.
>>>
>>> Anyway, something I wanted to point out:
>>> http://tools.android.com/tech-docs/new-build-system/gradle-experimental
>>> says as an example to use toolchainVersion = 3.4 for clang and r10e for the
>>> ndk is required. There is no 3.4 toolchain version of clang in r10e.
>>>
>>> Next, should mention that if users wish to use more than one srcDir for
>>> jni, use the srcDirs property and an arrayList. (i.e.
>>> android.sources {
>>> main {
>>> jni {
>>> source {
>>> srcDirs = [file('../../Android').absolutePath,
>>> file('../../../Common').absolutePath ]
>>> }
>>> }
>>> }
>>> }
>>>
>>> Also, apply plugin: 'com.android.model.library' should be somewhere in
>>> there as an option in the docs.
>>>
>>> CFlags and cppFlags have very similar oddities:
>>> cppFlags += " -I" + file('../../../Common').absolutePath
>>> will result in compiler errors that the file or directory <path>/Common
>>> is not found and it wont compile. However, remove the space prior to the
>>> -I flag and it's all good. I had to remove all spaces on front and back of
>>> all cflags and do a separate flag per line with cppFlags += <newFlag>
>>>
>>> I can get gradlew to run the compiler, but the GUI doesn't actually run
>>> the ndk build task. If I run the gradle task from the GUI :app:build then
>>> it does build the ndk build task but F9 gives me everything but.
>>>
>>> armeabi-v7 should be armeabi-v7a
>>>
>>> android.buildTypes { } should include isDebuggable = true and
>>> isJniDebuggable = true.
>>>
>>> For the life of me I couldn't get cppFlags +=
>>> "-DVERSION=\"${rootProject.getVersion().toString()}\"" to work. Am I doing
>>> something wrong with it?
>>>
>>> splits should now be android.splits <-- not listed. It would be nice to
>>> have a better way of defining abiFilters to only include what's asked for
>>> (i.e. set universalAPK to false elsewhere). Also should note that setting
>>> abiFilters has no barring on what will be compiled. The NDK will try to
>>> compile all abiFilters no matter what.
>>>
>>> That's as far as I could test. Going back to deprecated ndk scheme
>>> until the next version. Thought I'd give feedback.
>>>
>>>
>> On Thursday, July 9, 2015 at 6:10:17 PM UTC-7, Steven Winston wrote:
>>>
>>> It's very pleasant to see Google finally release this.
>>>
>>> First it's still quite sad that there is no mechanism to use older
>>> library builds with pre-existing .mk files. I get around this as I always
>>> have by creating own task that calls ndk-build.
>>>
>>> Anyway, something I wanted to point out:
>>> http://tools.android.com/tech-docs/new-build-system/gradle-experimental
>>> says as an example to use toolchainVersion = 3.4 for clang and r10e for the
>>> ndk is required. There is no 3.4 toolchain version of clang in r10e.
>>>
>>> Next, should mention that if users wish to use more than one srcDir for
>>> jni, use the srcDirs property and an arrayList. (i.e.
>>> android.sources {
>>> main {
>>> jni {
>>> source {
>>> srcDirs = [file('../../Android').absolutePath,
>>> file('../../../Common').absolutePath ]
>>> }
>>> }
>>> }
>>> }
>>>
>>> Also, apply plugin: 'com.android.model.library' should be somewhere in
>>> there as an option in the docs.
>>>
>>> CFlags and cppFlags have very similar oddities:
>>> cppFlags += " -I" + file('../../../Common').absolutePath
>>> will result in compiler errors that the file or directory <path>/Common
>>> is not found and it wont compile. However, remove the space prior to the
>>> -I flag and it's all good. I had to remove all spaces on front and back of
>>> all cflags and do a separate flag per line with cppFlags += <newFlag>
>>>
>>> I can get gradlew to run the compiler, but the GUI doesn't actually run
>>> the ndk build task. If I run the gradle task from the GUI :app:build then
>>> it does build the ndk build task but F9 gives me everything but.
>>>
>>> armeabi-v7 should be armeabi-v7a
>>>
>>> android.buildTypes { } should include isDebuggable = true and
>>> isJniDebuggable = true.
>>>
>>> For the life of me I couldn't get cppFlags +=
>>> "-DVERSION=\"${rootProject.getVersion().toString()}\"" to work. Am I doing
>>> something wrong with it?
>>>
>>> splits should now be android.splits <-- not listed. It would be nice to
>>> have a better way of defining abiFilters to only include what's asked for
>>> (i.e. set universalAPK to false elsewhere). Also should note that setting
>>> abiFilters has no barring on what will be compiled. The NDK will try to
>>> compile all abiFilters no matter what.
>>>
>>> That's as far as I could test. Going back to deprecated ndk scheme
>>> until the next version. Thought I'd give feedback.
>>>
>>>
>> On Thursday, July 9, 2015 at 6:10:17 PM UTC-7, Steven Winston wrote:
>>>
>>> It's very pleasant to see Google finally release this.
>>>
>>> First it's still quite sad that there is no mechanism to use older
>>> library builds with pre-existing .mk files. I get around this as I always
>>> have by creating own task that calls ndk-build.
>>>
>>> Anyway, something I wanted to point out:
>>> http://tools.android.com/tech-docs/new-build-system/gradle-experimental
>>> says as an example to use toolchainVersion = 3.4 for clang and r10e for the
>>> ndk is required. There is no 3.4 toolchain version of clang in r10e.
>>>
>>> Next, should mention that if users wish to use more than one srcDir for
>>> jni, use the srcDirs property and an arrayList. (i.e.
>>> android.sources {
>>> main {
>>> jni {
>>> source {
>>> srcDirs = [file('../../Android').absolutePath,
>>> file('../../../Common').absolutePath ]
>>> }
>>> }
>>> }
>>> }
>>>
>>> Also, apply plugin: 'com.android.model.library' should be somewhere in
>>> there as an option in the docs.
>>>
>>> CFlags and cppFlags have very similar oddities:
>>> cppFlags += " -I" + file('../../../Common').absolutePath
>>> will result in compiler errors that the file or directory <path>/Common
>>> is not found and it wont compile. However, remove the space prior to the
>>> -I flag and it's all good. I had to remove all spaces on front and back of
>>> all cflags and do a separate flag per line with cppFlags += <newFlag>
>>>
>>> I can get gradlew to run the compiler, but the GUI doesn't actually run
>>> the ndk build task. If I run the gradle task from the GUI :app:build then
>>> it does build the ndk build task but F9 gives me everything but.
>>>
>>> armeabi-v7 should be armeabi-v7a
>>>
>>> android.buildTypes { } should include isDebuggable = true and
>>> isJniDebuggable = true.
>>>
>>> For the life of me I couldn't get cppFlags +=
>>> "-DVERSION=\"${rootProject.getVersion().toString()}\"" to work. Am I doing
>>> something wrong with it?
>>>
>>> splits should now be android.splits <-- not listed. It would be nice to
>>> have a better way of defining abiFilters to only include what's asked for
>>> (i.e. set universalAPK to false elsewhere). Also should note that setting
>>> abiFilters has no barring on what will be compiled. The NDK will try to
>>> compile all abiFilters no matter what.
>>>
>>> That's as far as I could test. Going back to deprecated ndk scheme
>>> until the next version. Thought I'd give feedback.
>>>
>>>
--
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.
