[CMake] CMake + Gradle for Android

Mon Aug 21 12:00:19 EDT 2017

Thanks this is very helpful. The other question I have is: Is there a
place to centrally specify the root CMakeLists.txt? Basically, I want
to specify the CMake root in 1 place, and have targets (defined
further down in subdirectories) that require APK packaging to specify
only the native target name that should be built & packaged.

At the moment we specify the root CMakeLists.txt by walking up the
tree, paths like "../../../../CMakeLists.txt". I think this should be
put at the top-level build gradle file if possible. Is this doable at
the moment? What is the recommended setup?

On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher <jomofisher at gmail.com> wrote:
> Gradle does introspection on the CMake build to find .so targets and those
> get packaged.
> There is also a special case for stl/runtime .so files from the NDK.
> Any additional .so files need to specified in build.gradle using jniDirs
>
> On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey <rcdailey.lists at gmail.com>
> wrote:
>>
>> 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 <jomofisher at 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.lists at 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 <jomofisher at 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.lists at 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
>> >> >
>> >> >
>> >
>> >
>
>