Hello Raymond, Thanks so much; I tried the hybrid, however the order of operations seems to have changed somehow. My ndk build task is happening after a different module is trying to link to it. As I just saw that you fixed the ABI building everything bug, I'll wait until the next gradle release and try a deep dive again then. BTW, thanks so much for fixing that bug, looking forward to the next gradle release.
Once I get a stable build system setup, I'll try to make what I'm doing with gtest a bit more feature complete and then I'll submit a feature request surrounding it. Thanks! On Thu, Jul 23, 2015 at 10:56 AM, Raymond Chiu <[email protected]> wrote: > 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.
