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