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.
