How exactly does Gradle package *.so files in an APK? I know that ANT used to do this for any libs under "libs/<ABI>". Does Gradle do some introspection into CMake targets to see if outputs are *.so, and copy those to some location if needed? What about libraries like libgnustl_shared.so that come with the NDK? I'd like to know if any manual copy steps are needed in CMake to put outputs in proper locations for the APK build step. I had to do this when using ANT.
On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher <jomofis...@gmail.com> wrote: > 1) There is a folder created for each ABI under the project module folder > (so unique per module per ABI) > 2) Gradle doesn't specify language level though you can choose to specify it > yourself from the build.gradle. This doc does a pretty good job of > explaining which variables are set by Gradle: > https://developer.android.com/ndk/guides/cmake.html#variables. > Philosophically, we try to set as little as we can get away with. In > particular, the section titled "Understanding the CMake build command" lays > out exactly what we set. You can also see the folders we specify (one per > module per ABI) > 3) Not sure I understand this. > > The other document worth taking a look at (if you haven't already) is: > https://developer.android.com/studio/projects/add-native-code.html > > > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey <rcdailey.li...@gmail.com> > wrote: >> >> Thanks Jom >> >> Honestly, I prefer option 1 to work simply because that's how Google's >> officially supporting CMake. But it also has debugging which is the #1 >> reason for me. >> >> However, I'd like to understand a lot more about how the integration >> really happens. For example, I have these questions: >> >> 1) How, internally, are CMake build directories managed? Do you >> generate 1 per unique android project? What about for each specific >> platform (x86, armeabi-v7a, etc)? >> 2) Last time I looked into CMake integration, things defined inside >> the CMake scripts were ignored because they are specified at the >> command line. Namely, all of those settings that are driven by the >> Gradle configuration (CXX language level was one in particular I >> think; I specify C++14 support via CMake, but I recall this being >> overridden from outside)? >> 3) How redundant is it to configure individual libraries via the >> gradle scripts? In my previous attempts, I wanted to define common >> stuff for CMake / native code at the root gradle or settings file, and >> only define the differences in the actual gradle build files for each >> corresponding Java target (like, defining the name of the native >> (shared library) target in Gradle, but the command line invocation, -D >> CMake settings, etc would all be common and defined at the root). >> >> The TLDR is, the closer we can stay to CMake's way of doing things and >> keep CMake-related settings self-contained to the CMake scripts >> themselves, the better. This also makes cross-platform easier (we >> build the native code in Windows, for example, so having settings >> specified in the gradle files do not carry over to other platforms. >> Namely, settings that are not platform specific like the C++ language >> level). >> >> If there's a detailed document / wiki I can read on the intrinsics of >> CMake integration in Gradle / Android Studio, I'd love to read it. >> Otherwise, I hope you won't mind if I pick your brain as questions >> come up. I think I'm going to try option 1 for now and see how it >> goes. It's just black box for me because unlike option 2, I have very >> little control over what happens after building the shared libraries, >> and to make up for that I need to really get a deep understanding of >> how it works so I can make sure I code my CMake scripts properly for >> not only Android, but my other platforms as well (non-Android >> platforms). >> >> Thanks again. >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher <jomofis...@gmail.com> wrote: >> > Either option can work fine. Disclosure: I work on Android Studio and >> > was >> > the one that added CMake support. >> > >> > Option (1) is the way it's designed to work and we're working toward >> > getting >> > rid of the need for the CMake fork. I can't really say when that will >> > happen >> > but if you can get away with an older CMake for now then I'd go this >> > way. >> > As you mentioned, option (1) will allow you to view your source file >> > structure in Android Studio, edit files, and debug using the built-in >> > debugging support. >> > >> > To get option (2) to work, you can use jniDirs setting to tell Android >> > Gradle where to pick up your built .so files (see >> > >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >> > I'm not aware of any projects that use this approach but it should work >> > in >> > principal. >> > >> > I hope this helps, >> > Jomo >> > >> > >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >> > <rcdailey.li...@gmail.com> >> > wrote: >> >> >> >> Right now I have custom targets set to execute the "ant release" >> >> command after my native targets are built. Part of that command >> >> involves copying *.so files to the libs/armeabi-v7a directory so they >> >> get packaged in an APK. >> >> >> >> When switching to gradle, I have two options: >> >> >> >> 1. Gradle drives CMake: This means using Android Studio and being >> >> locked down to Google's fork of CMake which is a few major releases >> >> behind. I see that as a negative. >> >> >> >> 2. CMake drives Gradle: This would be the same or similar to what I'm >> >> already doing: The custom targets I have would execute gradle as a >> >> separate build step, instead of running ant commands. I'm not too >> >> familiar with Gradle, so I'm not sure how you tell it where your >> >> shared libraries are for the APK packaging steps. >> >> >> >> Which does everyone recommend? Is anyone using one of these setups >> >> successfully? The downside to option 2 is probably no on-device native >> >> debugging since Android Studio probably can't handle gradle projects >> >> without any external CMake builds set up. >> >> >> >> Would like some general direction & advice before I move away from >> >> ANT. Thanks in advance. >> >> -- >> >> >> >> Powered by www.kitware.com >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: >> >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >> >> Kitware offers various services to support the CMake community. For >> >> more >> >> information on each offering, please visit: >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/cmake >> > >> > > > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
