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
