CMake + Gradle for Android

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

CMake + Gradle for Android

Robert Dailey-2
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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Jom O'Fisher
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Robert Dailey-2
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 <[hidden email]> 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 <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Jom O'Fisher
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Eric Wing
Hi Jom,

I'm glad to hear Android's CMake will eventually catch up.

But since you are here, can you add a feature that allows a user to
specify an alternate location for where CMake is located? There are
two useful cases for this.

1) Users daring or desperate enough to try using a more recent CMake
while they wait (perhaps they could have merged with Google's branch
manually)

2) In my case, I'm trying to implement new features into CMake (Swift
compiler support). It's not going to be mainlined anytime soon since
it is a long project, so even when you catch up, I still need to be
able to call my fork of CMake.

I don't want to overwrite anything in the Android distribution, and I
have people using my stuff and helping me, so we need a way to
collaborate. A simple gradle argument that lets me specify an
alternative path to CMake would fix my problem. (The other things I
need are specifying a toolchain file which I think you already support
and an Initial Cache (-C switch) which maybe is implicitly supported
since it is just a generic CMake command line argument.


Right now, I am doing the alternative method of calling CMake myself
through Gradle/Groovy scripts as people used to do. But I never
figured out how to get debugger integration with Android Studio as a
consequence. I would really like to move to the official Google/CMake
support, but I can't do that unless I can invoke a different CMake. (I
did pull the Google fork of CMake and I think my changes are
mergable.)

Thanks,
Eric
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Jom O'Fisher
Yeah, we'd like to support any CMake more recent than 3.7.0 (which is the first version to support server mode). So your fork would need to be based on a somewhat recent CMake. We probably wouldn't support a path directly in build.gradle since that is typically a source controlled artifact. We'd let you set a file path in local.properties and/or specify a CMake version number in build.gradle where we'd search for it in some well-known locations. 


On Tue, Aug 8, 2017 at 5:21 PM, Eric Wing <[hidden email]> wrote:
Hi Jom,

I'm glad to hear Android's CMake will eventually catch up.

But since you are here, can you add a feature that allows a user to
specify an alternate location for where CMake is located? There are
two useful cases for this.

1) Users daring or desperate enough to try using a more recent CMake
while they wait (perhaps they could have merged with Google's branch
manually)

2) In my case, I'm trying to implement new features into CMake (Swift
compiler support). It's not going to be mainlined anytime soon since
it is a long project, so even when you catch up, I still need to be
able to call my fork of CMake.

I don't want to overwrite anything in the Android distribution, and I
have people using my stuff and helping me, so we need a way to
collaborate. A simple gradle argument that lets me specify an
alternative path to CMake would fix my problem. (The other things I
need are specifying a toolchain file which I think you already support
and an Initial Cache (-C switch) which maybe is implicitly supported
since it is just a generic CMake command line argument.


Right now, I am doing the alternative method of calling CMake myself
through Gradle/Groovy scripts as people used to do. But I never
figured out how to get debugger integration with Android Studio as a
consequence. I would really like to move to the official Google/CMake
support, but I can't do that unless I can invoke a different CMake. (I
did pull the Google fork of CMake and I think my changes are
mergable.)

Thanks,
Eric


--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Eric Wing
On 8/8/17, Jom O'Fisher <[hidden email]> wrote:
> Yeah, we'd like to support any CMake more recent than 3.7.0 (which is the
> first version to support server mode). So your fork would need to be based
> on a somewhat recent CMake. We probably wouldn't support a path directly in
> build.gradle since that is typically a source controlled artifact. We'd let
> you set a file path in local.properties and/or specify a CMake version
> number in build.gradle where we'd search for it in some well-known
> locations.

I think I could live with local.properties. Any chance you could fast
track this and get it in soon?

Somewhat coincidentally, my fork of CMake happened close to the time
of where the Google fork seemed to happen. I tried the merge. I got
tons of conflicts for other things, not my changes. I'm about half-way
resolving them...but my changeset is relatively small so I've been
thinking I might just manually repatch on yours or try the
cherry-picking feature of Git.

Thanks,
Eric
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Robert Dailey-2
In reply to this post by Jom O'Fisher
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Jom O'Fisher
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Robert Dailey-2
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
>> > 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 <[hidden email]>
>> >> 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
>> >> > <[hidden email]>
>> >> > 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Jom O'Fisher
What you're doing already sounds correct. You can't directly specify CMakeLists.txt from the top-level build.gradle. Recommendation is that it should be specified from the build.gradle of the module of the APK. Is the issue that you have multiple APK modules that all reference the same CMake libraries?

On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
>> > 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 <[hidden email]>
>> >> 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
>> >> > <[hidden email]>
>> >> > 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Robert Dailey-2
Basically, yes. We have this sort of structure:

<Root of git clone>/
    Applications/
        App1/
            build.gradle
            CMakeLists.txt
        App2/
            build.gradle
            CMakeLists.txt
        App3/
            build.gradle
            CMakeLists.txt
    CommonLib/
        build.gradle
        CMakeLists.txt
    CMakeLists.txt

The libs are defined as follows:

* CommonLib is a static library (java code builds into a library)
    * No dependencies of its own
* App1 is a shared library (java code builds into a library)
    * Dependencies (both java & native): CommonLib
* App2 is a shared library (java code builds into an APK)
   * Dependencies (both java & native): App1, CommonLib
* App3 is a shared library (java code builds into an APK)
   * Dependencies (both java & native): CommonLib

In all cases, CMake must be invoked starting at the root
CMakeLists.txt 1 time. Each target can be built from the same binary
directory after that. Previously with ANT, I was building all native
targets first, then moved libs to appropriate directories so that the
'ant' command would package the libs.

For gradle, I wanted to avoid redundantly specifying the root
directory in each leaf-level project directory. Using the example
above, the leaf-level directories in this case would be App1, App2,
App3, and CommonLib. However I think we only specify the native CMake
stuff for the java targets that actually output an APK (that would be
App2 and App3 only).

The ultimate goal is to specify stuff that doesn't change per
independent "module" of ours at the top level so it is transitive /
inherited. Then only specify the differences (e.g. the native CMake
target to build) in the leaf build gradle files. However you indicated
this isn't possible.



On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher <[hidden email]> wrote:

> What you're doing already sounds correct. You can't directly specify
> CMakeLists.txt from the top-level build.gradle. Recommendation is that it
> should be specified from the build.gradle of the module of the APK. Is the
> issue that you have multiple APK modules that all reference the same CMake
> libraries?
>
> On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey <[hidden email]>
> wrote:
>>
>> 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 <[hidden email]>
>> 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
>> > <[hidden email]>
>> > 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 <[hidden email]>
>> >> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> 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
>> >> >> > <[hidden email]>
>> >> >> > 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Jom O'Fisher
Would it work for your situation for the leaf CMakeLists.txt to include the root CMakeLists.txt? Then have the leaf-specific logic in the leaf CMakeLists.txt?



On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey <[hidden email]> wrote:
Basically, yes. We have this sort of structure:

<Root of git clone>/
    Applications/
        App1/
            build.gradle
            CMakeLists.txt
        App2/
            build.gradle
            CMakeLists.txt
        App3/
            build.gradle
            CMakeLists.txt
    CommonLib/
        build.gradle
        CMakeLists.txt
    CMakeLists.txt

The libs are defined as follows:

* CommonLib is a static library (java code builds into a library)
    * No dependencies of its own
* App1 is a shared library (java code builds into a library)
    * Dependencies (both java & native): CommonLib
* App2 is a shared library (java code builds into an APK)
   * Dependencies (both java & native): App1, CommonLib
* App3 is a shared library (java code builds into an APK)
   * Dependencies (both java & native): CommonLib

In all cases, CMake must be invoked starting at the root
CMakeLists.txt 1 time. Each target can be built from the same binary
directory after that. Previously with ANT, I was building all native
targets first, then moved libs to appropriate directories so that the
'ant' command would package the libs.

For gradle, I wanted to avoid redundantly specifying the root
directory in each leaf-level project directory. Using the example
above, the leaf-level directories in this case would be App1, App2,
App3, and CommonLib. However I think we only specify the native CMake
stuff for the java targets that actually output an APK (that would be
App2 and App3 only).

The ultimate goal is to specify stuff that doesn't change per
independent "module" of ours at the top level so it is transitive /
inherited. Then only specify the differences (e.g. the native CMake
target to build) in the leaf build gradle files. However you indicated
this isn't possible.



On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher <[hidden email]> wrote:
> What you're doing already sounds correct. You can't directly specify
> CMakeLists.txt from the top-level build.gradle. Recommendation is that it
> should be specified from the build.gradle of the module of the APK. Is the
> issue that you have multiple APK modules that all reference the same CMake
> libraries?
>
> On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey <[hidden email]>
> wrote:
>>
>> 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 <[hidden email]>
>> 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
>> > <[hidden email]>
>> > 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 <[hidden email]>
>> >> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> 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
>> >> >> > <[hidden email]>
>> >> >> > 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Robert Dailey-2
I wouldn't want to do that, it's too convoluted. I have other
platforms that use these CMake scripts as well. For example, I run on
Windows and Linux platforms as well to build the native code. Normal
CMake behavior is designed to work at a root then go downwards to find
targets. However it seems Gradle wants to start at a subdirectory and
work its way up to the root, which is opposite of CMake's intended
behavior IMHO. Not only that but I want to avoid special-casing
behavior in CMake just for Android's use.

At the moment it feels like (again referring back to my previous
example structure) that both App2 and App3 each run CMake in
independent binary directories instead of sharing 1 binary directory
and building 2 targets inside of it. I prefer this behavior instead,
especially since it allows CMake to operate as it was intended. I
think it's a common case that projects will define multiple targets
starting from a single root, and expect multiple APKs or java
dependencies to be built within it.

If I'm misunderstanding or making false assumptions please let me know.



On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher <[hidden email]> wrote:

> Would it work for your situation for the leaf CMakeLists.txt to include the
> root CMakeLists.txt? Then have the leaf-specific logic in the leaf
> CMakeLists.txt?
>
>
>
> On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey <[hidden email]>
> wrote:
>>
>> Basically, yes. We have this sort of structure:
>>
>> <Root of git clone>/
>>     Applications/
>>         App1/
>>             build.gradle
>>             CMakeLists.txt
>>         App2/
>>             build.gradle
>>             CMakeLists.txt
>>         App3/
>>             build.gradle
>>             CMakeLists.txt
>>     CommonLib/
>>         build.gradle
>>         CMakeLists.txt
>>     CMakeLists.txt
>>
>> The libs are defined as follows:
>>
>> * CommonLib is a static library (java code builds into a library)
>>     * No dependencies of its own
>> * App1 is a shared library (java code builds into a library)
>>     * Dependencies (both java & native): CommonLib
>> * App2 is a shared library (java code builds into an APK)
>>    * Dependencies (both java & native): App1, CommonLib
>> * App3 is a shared library (java code builds into an APK)
>>    * Dependencies (both java & native): CommonLib
>>
>> In all cases, CMake must be invoked starting at the root
>> CMakeLists.txt 1 time. Each target can be built from the same binary
>> directory after that. Previously with ANT, I was building all native
>> targets first, then moved libs to appropriate directories so that the
>> 'ant' command would package the libs.
>>
>> For gradle, I wanted to avoid redundantly specifying the root
>> directory in each leaf-level project directory. Using the example
>> above, the leaf-level directories in this case would be App1, App2,
>> App3, and CommonLib. However I think we only specify the native CMake
>> stuff for the java targets that actually output an APK (that would be
>> App2 and App3 only).
>>
>> The ultimate goal is to specify stuff that doesn't change per
>> independent "module" of ours at the top level so it is transitive /
>> inherited. Then only specify the differences (e.g. the native CMake
>> target to build) in the leaf build gradle files. However you indicated
>> this isn't possible.
>>
>>
>>
>> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher <[hidden email]>
>> wrote:
>> > What you're doing already sounds correct. You can't directly specify
>> > CMakeLists.txt from the top-level build.gradle. Recommendation is that
>> > it
>> > should be specified from the build.gradle of the module of the APK. Is
>> > the
>> > issue that you have multiple APK modules that all reference the same
>> > CMake
>> > libraries?
>> >
>> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey
>> > <[hidden email]>
>> > wrote:
>> >>
>> >> 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 <[hidden email]>
>> >> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> 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
>> >> >> > <[hidden email]>
>> >> >> > 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
>> >> >> >> <[hidden email]>
>> >> >> >> 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
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Jom O'Fisher
Would it work for your scenario to provide properties in the root build.gradle:
ext {
cmakePath = file "CMakeLists.txt"
}
And then consume them in the leaf app/build.gradle like this?
externalNativeBuild {
cmake {
path cmakePath
}
}
It doesn't fully hide the details but it does centralize the information.

On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey <[hidden email]> wrote:
I wouldn't want to do that, it's too convoluted. I have other
platforms that use these CMake scripts as well. For example, I run on
Windows and Linux platforms as well to build the native code. Normal
CMake behavior is designed to work at a root then go downwards to find
targets. However it seems Gradle wants to start at a subdirectory and
work its way up to the root, which is opposite of CMake's intended
behavior IMHO. Not only that but I want to avoid special-casing
behavior in CMake just for Android's use.

At the moment it feels like (again referring back to my previous
example structure) that both App2 and App3 each run CMake in
independent binary directories instead of sharing 1 binary directory
and building 2 targets inside of it. I prefer this behavior instead,
especially since it allows CMake to operate as it was intended. I
think it's a common case that projects will define multiple targets
starting from a single root, and expect multiple APKs or java
dependencies to be built within it.

If I'm misunderstanding or making false assumptions please let me know.



On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher <[hidden email]> wrote:
> Would it work for your situation for the leaf CMakeLists.txt to include the
> root CMakeLists.txt? Then have the leaf-specific logic in the leaf
> CMakeLists.txt?
>
>
>
> On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey <[hidden email]>
> wrote:
>>
>> Basically, yes. We have this sort of structure:
>>
>> <Root of git clone>/
>>     Applications/
>>         App1/
>>             build.gradle
>>             CMakeLists.txt
>>         App2/
>>             build.gradle
>>             CMakeLists.txt
>>         App3/
>>             build.gradle
>>             CMakeLists.txt
>>     CommonLib/
>>         build.gradle
>>         CMakeLists.txt
>>     CMakeLists.txt
>>
>> The libs are defined as follows:
>>
>> * CommonLib is a static library (java code builds into a library)
>>     * No dependencies of its own
>> * App1 is a shared library (java code builds into a library)
>>     * Dependencies (both java & native): CommonLib
>> * App2 is a shared library (java code builds into an APK)
>>    * Dependencies (both java & native): App1, CommonLib
>> * App3 is a shared library (java code builds into an APK)
>>    * Dependencies (both java & native): CommonLib
>>
>> In all cases, CMake must be invoked starting at the root
>> CMakeLists.txt 1 time. Each target can be built from the same binary
>> directory after that. Previously with ANT, I was building all native
>> targets first, then moved libs to appropriate directories so that the
>> 'ant' command would package the libs.
>>
>> For gradle, I wanted to avoid redundantly specifying the root
>> directory in each leaf-level project directory. Using the example
>> above, the leaf-level directories in this case would be App1, App2,
>> App3, and CommonLib. However I think we only specify the native CMake
>> stuff for the java targets that actually output an APK (that would be
>> App2 and App3 only).
>>
>> The ultimate goal is to specify stuff that doesn't change per
>> independent "module" of ours at the top level so it is transitive /
>> inherited. Then only specify the differences (e.g. the native CMake
>> target to build) in the leaf build gradle files. However you indicated
>> this isn't possible.
>>
>>
>>
>> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher <[hidden email]>
>> wrote:
>> > What you're doing already sounds correct. You can't directly specify
>> > CMakeLists.txt from the top-level build.gradle. Recommendation is that
>> > it
>> > should be specified from the build.gradle of the module of the APK. Is
>> > the
>> > issue that you have multiple APK modules that all reference the same
>> > CMake
>> > libraries?
>> >
>> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey
>> > <[hidden email]>
>> > wrote:
>> >>
>> >> 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 <[hidden email]>
>> >> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> 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
>> >> >> > <[hidden email]>
>> >> >> > 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
>> >> >> >> <[hidden email]>
>> >> >> >> 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
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Robert Dailey-2
This definitely a bit better, but still requires the boilerplate in
each leaf gradle file. But I can't seriously complain too much. I
think I'm more concerned with the implications this has underneath.
First, let me ask just to make sure I'm not misunderstanding: Does
each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR?
How many binary dirs do you manage internally and what determines when
they get created?

On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher <[hidden email]> wrote:

> Would it work for your scenario to provide properties in the root
> build.gradle:
>
> ext {
>     cmakePath = file "CMakeLists.txt"
> }
>
> And then consume them in the leaf app/build.gradle like this?
>
> externalNativeBuild {
>     cmake {
>         path cmakePath
>     }
> }
>
> It doesn't fully hide the details but it does centralize the information.
>
>
> On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey <[hidden email]>
> wrote:
>>
>> I wouldn't want to do that, it's too convoluted. I have other
>> platforms that use these CMake scripts as well. For example, I run on
>> Windows and Linux platforms as well to build the native code. Normal
>> CMake behavior is designed to work at a root then go downwards to find
>> targets. However it seems Gradle wants to start at a subdirectory and
>> work its way up to the root, which is opposite of CMake's intended
>> behavior IMHO. Not only that but I want to avoid special-casing
>> behavior in CMake just for Android's use.
>>
>> At the moment it feels like (again referring back to my previous
>> example structure) that both App2 and App3 each run CMake in
>> independent binary directories instead of sharing 1 binary directory
>> and building 2 targets inside of it. I prefer this behavior instead,
>> especially since it allows CMake to operate as it was intended. I
>> think it's a common case that projects will define multiple targets
>> starting from a single root, and expect multiple APKs or java
>> dependencies to be built within it.
>>
>> If I'm misunderstanding or making false assumptions please let me know.
>>
>>
>>
>> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher <[hidden email]>
>> wrote:
>> > Would it work for your situation for the leaf CMakeLists.txt to include
>> > the
>> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf
>> > CMakeLists.txt?
>> >
>> >
>> >
>> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey
>> > <[hidden email]>
>> > wrote:
>> >>
>> >> Basically, yes. We have this sort of structure:
>> >>
>> >> <Root of git clone>/
>> >>     Applications/
>> >>         App1/
>> >>             build.gradle
>> >>             CMakeLists.txt
>> >>         App2/
>> >>             build.gradle
>> >>             CMakeLists.txt
>> >>         App3/
>> >>             build.gradle
>> >>             CMakeLists.txt
>> >>     CommonLib/
>> >>         build.gradle
>> >>         CMakeLists.txt
>> >>     CMakeLists.txt
>> >>
>> >> The libs are defined as follows:
>> >>
>> >> * CommonLib is a static library (java code builds into a library)
>> >>     * No dependencies of its own
>> >> * App1 is a shared library (java code builds into a library)
>> >>     * Dependencies (both java & native): CommonLib
>> >> * App2 is a shared library (java code builds into an APK)
>> >>    * Dependencies (both java & native): App1, CommonLib
>> >> * App3 is a shared library (java code builds into an APK)
>> >>    * Dependencies (both java & native): CommonLib
>> >>
>> >> In all cases, CMake must be invoked starting at the root
>> >> CMakeLists.txt 1 time. Each target can be built from the same binary
>> >> directory after that. Previously with ANT, I was building all native
>> >> targets first, then moved libs to appropriate directories so that the
>> >> 'ant' command would package the libs.
>> >>
>> >> For gradle, I wanted to avoid redundantly specifying the root
>> >> directory in each leaf-level project directory. Using the example
>> >> above, the leaf-level directories in this case would be App1, App2,
>> >> App3, and CommonLib. However I think we only specify the native CMake
>> >> stuff for the java targets that actually output an APK (that would be
>> >> App2 and App3 only).
>> >>
>> >> The ultimate goal is to specify stuff that doesn't change per
>> >> independent "module" of ours at the top level so it is transitive /
>> >> inherited. Then only specify the differences (e.g. the native CMake
>> >> target to build) in the leaf build gradle files. However you indicated
>> >> this isn't possible.
>> >>
>> >>
>> >>
>> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher <[hidden email]>
>> >> wrote:
>> >> > What you're doing already sounds correct. You can't directly specify
>> >> > CMakeLists.txt from the top-level build.gradle. Recommendation is
>> >> > that
>> >> > it
>> >> > should be specified from the build.gradle of the module of the APK.
>> >> > Is
>> >> > the
>> >> > issue that you have multiple APK modules that all reference the same
>> >> > CMake
>> >> > libraries?
>> >> >
>> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey
>> >> > <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> 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 <[hidden email]>
>> >> >> 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
>> >> >> > <[hidden email]>
>> >> >> > 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
>> >> >> >> <[hidden email]>
>> >> >> >> 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
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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
>> >> >> >> >> <[hidden email]>
>> >> >> >> >> 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
>> >> >> >> >> > <[hidden email]>
>> >> >> >> >> > 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Jom O'Fisher
You can find that number like this:
- x = number of externalNativeBuild.cmake.path in your build.gradle files
- y = number of gradle configurations (like debug and release)
- z = number of ABIs that you build

The result is x * y * z. To be more accurate, you should consider y and z to be functions of each build.gradle file since these can vary.

There is a second set of folders that hold the stripped versions of the .so files that is purely managed by the android gradle plugin, so you might consider the answer to be 2 * x * y * z.

Hope this helps.






On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey <[hidden email]> wrote:
This definitely a bit better, but still requires the boilerplate in
each leaf gradle file. But I can't seriously complain too much. I
think I'm more concerned with the implications this has underneath.
First, let me ask just to make sure I'm not misunderstanding: Does
each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR?
How many binary dirs do you manage internally and what determines when
they get created?

On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher <[hidden email]> wrote:
> Would it work for your scenario to provide properties in the root
> build.gradle:
>
> ext {
>     cmakePath = file "CMakeLists.txt"
> }
>
> And then consume them in the leaf app/build.gradle like this?
>
> externalNativeBuild {
>     cmake {
>         path cmakePath
>     }
> }
>
> It doesn't fully hide the details but it does centralize the information.
>
>
> On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey <[hidden email]>
> wrote:
>>
>> I wouldn't want to do that, it's too convoluted. I have other
>> platforms that use these CMake scripts as well. For example, I run on
>> Windows and Linux platforms as well to build the native code. Normal
>> CMake behavior is designed to work at a root then go downwards to find
>> targets. However it seems Gradle wants to start at a subdirectory and
>> work its way up to the root, which is opposite of CMake's intended
>> behavior IMHO. Not only that but I want to avoid special-casing
>> behavior in CMake just for Android's use.
>>
>> At the moment it feels like (again referring back to my previous
>> example structure) that both App2 and App3 each run CMake in
>> independent binary directories instead of sharing 1 binary directory
>> and building 2 targets inside of it. I prefer this behavior instead,
>> especially since it allows CMake to operate as it was intended. I
>> think it's a common case that projects will define multiple targets
>> starting from a single root, and expect multiple APKs or java
>> dependencies to be built within it.
>>
>> If I'm misunderstanding or making false assumptions please let me know.
>>
>>
>>
>> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher <[hidden email]>
>> wrote:
>> > Would it work for your situation for the leaf CMakeLists.txt to include
>> > the
>> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf
>> > CMakeLists.txt?
>> >
>> >
>> >
>> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey
>> > <[hidden email]>
>> > wrote:
>> >>
>> >> Basically, yes. We have this sort of structure:
>> >>
>> >> <Root of git clone>/
>> >>     Applications/
>> >>         App1/
>> >>             build.gradle
>> >>             CMakeLists.txt
>> >>         App2/
>> >>             build.gradle
>> >>             CMakeLists.txt
>> >>         App3/
>> >>             build.gradle
>> >>             CMakeLists.txt
>> >>     CommonLib/
>> >>         build.gradle
>> >>         CMakeLists.txt
>> >>     CMakeLists.txt
>> >>
>> >> The libs are defined as follows:
>> >>
>> >> * CommonLib is a static library (java code builds into a library)
>> >>     * No dependencies of its own
>> >> * App1 is a shared library (java code builds into a library)
>> >>     * Dependencies (both java & native): CommonLib
>> >> * App2 is a shared library (java code builds into an APK)
>> >>    * Dependencies (both java & native): App1, CommonLib
>> >> * App3 is a shared library (java code builds into an APK)
>> >>    * Dependencies (both java & native): CommonLib
>> >>
>> >> In all cases, CMake must be invoked starting at the root
>> >> CMakeLists.txt 1 time. Each target can be built from the same binary
>> >> directory after that. Previously with ANT, I was building all native
>> >> targets first, then moved libs to appropriate directories so that the
>> >> 'ant' command would package the libs.
>> >>
>> >> For gradle, I wanted to avoid redundantly specifying the root
>> >> directory in each leaf-level project directory. Using the example
>> >> above, the leaf-level directories in this case would be App1, App2,
>> >> App3, and CommonLib. However I think we only specify the native CMake
>> >> stuff for the java targets that actually output an APK (that would be
>> >> App2 and App3 only).
>> >>
>> >> The ultimate goal is to specify stuff that doesn't change per
>> >> independent "module" of ours at the top level so it is transitive /
>> >> inherited. Then only specify the differences (e.g. the native CMake
>> >> target to build) in the leaf build gradle files. However you indicated
>> >> this isn't possible.
>> >>
>> >>
>> >>
>> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher <[hidden email]>
>> >> wrote:
>> >> > What you're doing already sounds correct. You can't directly specify
>> >> > CMakeLists.txt from the top-level build.gradle. Recommendation is
>> >> > that
>> >> > it
>> >> > should be specified from the build.gradle of the module of the APK.
>> >> > Is
>> >> > the
>> >> > issue that you have multiple APK modules that all reference the same
>> >> > CMake
>> >> > libraries?
>> >> >
>> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey
>> >> > <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> 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 <[hidden email]>
>> >> >> 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
>> >> >> > <[hidden email]>
>> >> >> > 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
>> >> >> >> <[hidden email]>
>> >> >> >> 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
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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
>> >> >> >> >> <[hidden email]>
>> >> >> >> >> 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
>> >> >> >> >> > <[hidden email]>
>> >> >> >> >> > 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Jom O'Fisher
+ a colleague  

On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher <[hidden email]> wrote:
You can find that number like this:
- x = number of externalNativeBuild.cmake.path in your build.gradle files
- y = number of gradle configurations (like debug and release)
- z = number of ABIs that you build

The result is x * y * z. To be more accurate, you should consider y and z to be functions of each build.gradle file since these can vary.

There is a second set of folders that hold the stripped versions of the .so files that is purely managed by the android gradle plugin, so you might consider the answer to be 2 * x * y * z.

Hope this helps.






On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey <[hidden email]> wrote:
This definitely a bit better, but still requires the boilerplate in
each leaf gradle file. But I can't seriously complain too much. I
think I'm more concerned with the implications this has underneath.
First, let me ask just to make sure I'm not misunderstanding: Does
each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR?
How many binary dirs do you manage internally and what determines when
they get created?

On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher <[hidden email]> wrote:
> Would it work for your scenario to provide properties in the root
> build.gradle:
>
> ext {
>     cmakePath = file "CMakeLists.txt"
> }
>
> And then consume them in the leaf app/build.gradle like this?
>
> externalNativeBuild {
>     cmake {
>         path cmakePath
>     }
> }
>
> It doesn't fully hide the details but it does centralize the information.
>
>
> On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey <[hidden email]>
> wrote:
>>
>> I wouldn't want to do that, it's too convoluted. I have other
>> platforms that use these CMake scripts as well. For example, I run on
>> Windows and Linux platforms as well to build the native code. Normal
>> CMake behavior is designed to work at a root then go downwards to find
>> targets. However it seems Gradle wants to start at a subdirectory and
>> work its way up to the root, which is opposite of CMake's intended
>> behavior IMHO. Not only that but I want to avoid special-casing
>> behavior in CMake just for Android's use.
>>
>> At the moment it feels like (again referring back to my previous
>> example structure) that both App2 and App3 each run CMake in
>> independent binary directories instead of sharing 1 binary directory
>> and building 2 targets inside of it. I prefer this behavior instead,
>> especially since it allows CMake to operate as it was intended. I
>> think it's a common case that projects will define multiple targets
>> starting from a single root, and expect multiple APKs or java
>> dependencies to be built within it.
>>
>> If I'm misunderstanding or making false assumptions please let me know.
>>
>>
>>
>> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher <[hidden email]>
>> wrote:
>> > Would it work for your situation for the leaf CMakeLists.txt to include
>> > the
>> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf
>> > CMakeLists.txt?
>> >
>> >
>> >
>> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey
>> > <[hidden email]>
>> > wrote:
>> >>
>> >> Basically, yes. We have this sort of structure:
>> >>
>> >> <Root of git clone>/
>> >>     Applications/
>> >>         App1/
>> >>             build.gradle
>> >>             CMakeLists.txt
>> >>         App2/
>> >>             build.gradle
>> >>             CMakeLists.txt
>> >>         App3/
>> >>             build.gradle
>> >>             CMakeLists.txt
>> >>     CommonLib/
>> >>         build.gradle
>> >>         CMakeLists.txt
>> >>     CMakeLists.txt
>> >>
>> >> The libs are defined as follows:
>> >>
>> >> * CommonLib is a static library (java code builds into a library)
>> >>     * No dependencies of its own
>> >> * App1 is a shared library (java code builds into a library)
>> >>     * Dependencies (both java & native): CommonLib
>> >> * App2 is a shared library (java code builds into an APK)
>> >>    * Dependencies (both java & native): App1, CommonLib
>> >> * App3 is a shared library (java code builds into an APK)
>> >>    * Dependencies (both java & native): CommonLib
>> >>
>> >> In all cases, CMake must be invoked starting at the root
>> >> CMakeLists.txt 1 time. Each target can be built from the same binary
>> >> directory after that. Previously with ANT, I was building all native
>> >> targets first, then moved libs to appropriate directories so that the
>> >> 'ant' command would package the libs.
>> >>
>> >> For gradle, I wanted to avoid redundantly specifying the root
>> >> directory in each leaf-level project directory. Using the example
>> >> above, the leaf-level directories in this case would be App1, App2,
>> >> App3, and CommonLib. However I think we only specify the native CMake
>> >> stuff for the java targets that actually output an APK (that would be
>> >> App2 and App3 only).
>> >>
>> >> The ultimate goal is to specify stuff that doesn't change per
>> >> independent "module" of ours at the top level so it is transitive /
>> >> inherited. Then only specify the differences (e.g. the native CMake
>> >> target to build) in the leaf build gradle files. However you indicated
>> >> this isn't possible.
>> >>
>> >>
>> >>
>> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher <[hidden email]>
>> >> wrote:
>> >> > What you're doing already sounds correct. You can't directly specify
>> >> > CMakeLists.txt from the top-level build.gradle. Recommendation is
>> >> > that
>> >> > it
>> >> > should be specified from the build.gradle of the module of the APK.
>> >> > Is
>> >> > the
>> >> > issue that you have multiple APK modules that all reference the same
>> >> > CMake
>> >> > libraries?
>> >> >
>> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey
>> >> > <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> 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 <[hidden email]>
>> >> >> 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
>> >> >> > <[hidden email]>
>> >> >> > 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
>> >> >> >> <[hidden email]>
>> >> >> >> 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
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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
>> >> >> >> >> <[hidden email]>
>> >> >> >> >> 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
>> >> >> >> >> > <[hidden email]>
>> >> >> >> >> > 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Robert Dailey-2
Thanks to both of you for responding.

First, to Jom's reply: The "x" part is what I was worried about. Each
"path" resulting in a single binary dir. This is the part that I think
could be optimized. I'll explain more on this later. Note also that
this optimization might only benefit my specific structure, but I'd
also like to talk about that a bit more to understand if the structure
itself should be changed (of course any changes I can do will be
limited and might be very involved, but still we can hash out
different ideas).

So by "cross platform" here I mean that we build our C++ code (using
CMake to facilitate the build) on 4 different platforms at the moment:

- Windows using MSVC 2015 (We manage a "simulator" for our Android
apps via Win32 apps)
- Linux x86 (Ubuntu) using system Clang compiler (we use this to run
our unit tests)
- Android x86
- Android ARM

All of our android apps are basically games. They are probably 95% C++
code. We limit logic to java as much as possible because we want
behavior to be as cross platform as possible. Java code pretty much is
the minimum required. Enough to load our SO library files and do some
basic activity management (like going into background, setting up
opengl, etc)

Our root CMakeLists.txt does just a few things:

* Include our common CMake modules (that we manage) that set up a few
convenient CMake functions for creating targets, setting up unit
tests, including third party libs, etc.
* Runs add_subdirectory() to start including the sub-projects in our tree

The root CMakeLists.txt is extremely important because it sets up our
"CMake Environment", if you will, but doesn't actually define any
targets by itself. All CMakeLists.txt below it depend on the root
script being executed first, because they depend on the functions &
such that it defines.

Once CMake steps into "Applications", there is another CMakeLists.txt
that includes more directories. Each sibling directory represents the
root of a gradle project. Each of these has its own build.gradle
inside it. We use gradle to manage dependencies across applications
for Java dependencies. CMake maintains dependencies across apps for
dependencies on the native side.

Using App2 as an example, here is how the behavior differs per platform:

* Windows: Includes certain Windows-only CPP files (e.g.
win32main.cpp). This will set up the Win32 window, WinMain entry
point, etc. Basically everything required to run this code on Windows
(game will render to a window using OpenGL). Output is an executable
target (.exe).
* Android: Include Android-only CPP files (e.g. androidmain.cpp). This
defines functions like JNI_OnLoad(), android_main(), sets up JNI
bindings, and whatever else is required for our game to run on
Android. Output is a shared library target (.so) for packaging into
APK by gradle.
* Linux: Include linux-only files, mainly for running unit tests
specific to App2. Output is an executable target that runs various
test cases.

Most apps follow this pattern shown above. Each App# has mostly CPP
files that are built common to all platforms. Note that this way of
managing applications and libraries is how we keep our code base
modular. We do not structure anything specific to a particular
platform, we chose this structure because (up until gradle) it worked
well between our various build platforms.

Ideally, now that I understand how CMake is being managed by Gradle,
I'd like CMake to be managed as follows:

* The root build.gradle points to the "entry point" script for CMake
(this is our root CMakeLists.txt that does not define any targets).
This yields 1 binary directory per platform + configuration
combination (y * z) but does not duplicate it per sub-project (this
gets rid of 'x'). Example of what would be in the root build.gradle
(or gradle settings?) (note that this would not yield an actual java
target in gradle, it's just some property definition used by leaf
build gradle files; so i'm not sure if this is the appropriate way to
define that):

externalNativeBuild {
    cmake {
        path CMakeLists.txt
    }
}

* Each sub-project build.gradle has a new property under
externalNativeBuild called "cmake_target" or something, where I
specify the native target that should be built in the single binary
directory for that platform & configuration. So for App2's
build.gradle this would be:

externalNativeBuild {
    cmake {
        target App2
    }
}

This would error out if a `path` has not been defined at this or some
ancestor gradle script (assuming that gradle properties are transitive
like CMake's)

This structure seems a lot better to be. Again, it definitely benefits
our specific structure but I also am not sure if we're an exception to
the rule. It seems difficult to decompose and modularize a code base
without doing things this way, especially when it needs to work for
platforms other than Android itself.

On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu <[hidden email]> wrote:

> Hi Robert,
>
> I work with Jom on the Android Studio team, and I would like to clarify a
> few things to better understand your situation.
> You mentioned the project is intend to be cross platform.  Normally, in such
> situation, we expect there to be a single CMake root project to be imported
> into one of the Android library/application.  However, in your case, there
> are subprojects with Java code.
>
> Are the CMake code in App1/2/3 intended to be cross platform too?  Or are
> they Android specific code?  If they are meant to be cross platform, how
> does the Java code works on other platforms?  Or perhaps you added Java
> binding in those subprojects just for Android?
>
> The build.gradle in CommonLib, what kind of Gradle project is that?  From
> your description, it doesn't look like an Android library project.  Or am I
> mistaken and it also applies the android library plugin?
>
> Raymond
>
> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher <[hidden email]> wrote:
>>
>> + a colleague
>>
>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher <[hidden email]>
>> wrote:
>>>
>>> You can find that number like this:
>>> - x = number of externalNativeBuild.cmake.path in your build.gradle files
>>> - y = number of gradle configurations (like debug and release)
>>> - z = number of ABIs that you build
>>>
>>> The result is x * y * z. To be more accurate, you should consider y and z
>>> to be functions of each build.gradle file since these can vary.
>>>
>>> There is a second set of folders that hold the stripped versions of the
>>> .so files that is purely managed by the android gradle plugin, so you might
>>> consider the answer to be 2 * x * y * z.
>>>
>>> Hope this helps.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey <[hidden email]>
>>> wrote:
>>>>
>>>> This definitely a bit better, but still requires the boilerplate in
>>>> each leaf gradle file. But I can't seriously complain too much. I
>>>> think I'm more concerned with the implications this has underneath.
>>>> First, let me ask just to make sure I'm not misunderstanding: Does
>>>> each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR?
>>>> How many binary dirs do you manage internally and what determines when
>>>> they get created?
>>>>
>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher <[hidden email]>
>>>> wrote:
>>>> > Would it work for your scenario to provide properties in the root
>>>> > build.gradle:
>>>> >
>>>> > ext {
>>>> >     cmakePath = file "CMakeLists.txt"
>>>> > }
>>>> >
>>>> > And then consume them in the leaf app/build.gradle like this?
>>>> >
>>>> > externalNativeBuild {
>>>> >     cmake {
>>>> >         path cmakePath
>>>> >     }
>>>> > }
>>>> >
>>>> > It doesn't fully hide the details but it does centralize the
>>>> > information.
>>>> >
>>>> >
>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey
>>>> > <[hidden email]>
>>>> > wrote:
>>>> >>
>>>> >> I wouldn't want to do that, it's too convoluted. I have other
>>>> >> platforms that use these CMake scripts as well. For example, I run on
>>>> >> Windows and Linux platforms as well to build the native code. Normal
>>>> >> CMake behavior is designed to work at a root then go downwards to
>>>> >> find
>>>> >> targets. However it seems Gradle wants to start at a subdirectory and
>>>> >> work its way up to the root, which is opposite of CMake's intended
>>>> >> behavior IMHO. Not only that but I want to avoid special-casing
>>>> >> behavior in CMake just for Android's use.
>>>> >>
>>>> >> At the moment it feels like (again referring back to my previous
>>>> >> example structure) that both App2 and App3 each run CMake in
>>>> >> independent binary directories instead of sharing 1 binary directory
>>>> >> and building 2 targets inside of it. I prefer this behavior instead,
>>>> >> especially since it allows CMake to operate as it was intended. I
>>>> >> think it's a common case that projects will define multiple targets
>>>> >> starting from a single root, and expect multiple APKs or java
>>>> >> dependencies to be built within it.
>>>> >>
>>>> >> If I'm misunderstanding or making false assumptions please let me
>>>> >> know.
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher <[hidden email]>
>>>> >> wrote:
>>>> >> > Would it work for your situation for the leaf CMakeLists.txt to
>>>> >> > include
>>>> >> > the
>>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf
>>>> >> > CMakeLists.txt?
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey
>>>> >> > <[hidden email]>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >> Basically, yes. We have this sort of structure:
>>>> >> >>
>>>> >> >> <Root of git clone>/
>>>> >> >>     Applications/
>>>> >> >>         App1/
>>>> >> >>             build.gradle
>>>> >> >>             CMakeLists.txt
>>>> >> >>         App2/
>>>> >> >>             build.gradle
>>>> >> >>             CMakeLists.txt
>>>> >> >>         App3/
>>>> >> >>             build.gradle
>>>> >> >>             CMakeLists.txt
>>>> >> >>     CommonLib/
>>>> >> >>         build.gradle
>>>> >> >>         CMakeLists.txt
>>>> >> >>     CMakeLists.txt
>>>> >> >>
>>>> >> >> The libs are defined as follows:
>>>> >> >>
>>>> >> >> * CommonLib is a static library (java code builds into a library)
>>>> >> >>     * No dependencies of its own
>>>> >> >> * App1 is a shared library (java code builds into a library)
>>>> >> >>     * Dependencies (both java & native): CommonLib
>>>> >> >> * App2 is a shared library (java code builds into an APK)
>>>> >> >>    * Dependencies (both java & native): App1, CommonLib
>>>> >> >> * App3 is a shared library (java code builds into an APK)
>>>> >> >>    * Dependencies (both java & native): CommonLib
>>>> >> >>
>>>> >> >> In all cases, CMake must be invoked starting at the root
>>>> >> >> CMakeLists.txt 1 time. Each target can be built from the same
>>>> >> >> binary
>>>> >> >> directory after that. Previously with ANT, I was building all
>>>> >> >> native
>>>> >> >> targets first, then moved libs to appropriate directories so that
>>>> >> >> the
>>>> >> >> 'ant' command would package the libs.
>>>> >> >>
>>>> >> >> For gradle, I wanted to avoid redundantly specifying the root
>>>> >> >> directory in each leaf-level project directory. Using the example
>>>> >> >> above, the leaf-level directories in this case would be App1,
>>>> >> >> App2,
>>>> >> >> App3, and CommonLib. However I think we only specify the native
>>>> >> >> CMake
>>>> >> >> stuff for the java targets that actually output an APK (that would
>>>> >> >> be
>>>> >> >> App2 and App3 only).
>>>> >> >>
>>>> >> >> The ultimate goal is to specify stuff that doesn't change per
>>>> >> >> independent "module" of ours at the top level so it is transitive
>>>> >> >> /
>>>> >> >> inherited. Then only specify the differences (e.g. the native
>>>> >> >> CMake
>>>> >> >> target to build) in the leaf build gradle files. However you
>>>> >> >> indicated
>>>> >> >> this isn't possible.
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher
>>>> >> >> <[hidden email]>
>>>> >> >> wrote:
>>>> >> >> > What you're doing already sounds correct. You can't directly
>>>> >> >> > specify
>>>> >> >> > CMakeLists.txt from the top-level build.gradle. Recommendation
>>>> >> >> > is
>>>> >> >> > that
>>>> >> >> > it
>>>> >> >> > should be specified from the build.gradle of the module of the
>>>> >> >> > APK.
>>>> >> >> > Is
>>>> >> >> > the
>>>> >> >> > issue that you have multiple APK modules that all reference the
>>>> >> >> > same
>>>> >> >> > CMake
>>>> >> >> > libraries?
>>>> >> >> >
>>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey
>>>> >> >> > <[hidden email]>
>>>> >> >> > wrote:
>>>> >> >> >>
>>>> >> >> >> 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
>>>> >> >> >> <[hidden email]>
>>>> >> >> >> 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
>>>> >> >> >> > <[hidden email]>
>>>> >> >> >> > 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
>>>> >> >> >> >> <[hidden email]>
>>>> >> >> >> >> 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
>>>> >> >> >> >> > <[hidden email]>
>>>> >> >> >> >> > 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
>>>> >> >> >> >> >> <[hidden email]>
>>>> >> >> >> >> >> 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
>>>> >> >> >> >> >> > <[hidden email]>
>>>> >> >> >> >> >> > 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake + Gradle for Android

Robert Dailey-2
In reply to this post by Jom O'Fisher
Sorry I forgot to answer your last set of questions:

CommonLib is indeed 2 things:

* A common (static or shared) library for native code (most of our
CMake targets specify CommonLib as a link dependency)
* A common library for Java code (we do specify this as a dependency
for most java targets in Gradle, specifically those under
Applications/)

On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu <[hidden email]> wrote:

> Hi Robert,
>
> I work with Jom on the Android Studio team, and I would like to clarify a
> few things to better understand your situation.
> You mentioned the project is intend to be cross platform.  Normally, in such
> situation, we expect there to be a single CMake root project to be imported
> into one of the Android library/application.  However, in your case, there
> are subprojects with Java code.
>
> Are the CMake code in App1/2/3 intended to be cross platform too?  Or are
> they Android specific code?  If they are meant to be cross platform, how
> does the Java code works on other platforms?  Or perhaps you added Java
> binding in those subprojects just for Android?
>
> The build.gradle in CommonLib, what kind of Gradle project is that?  From
> your description, it doesn't look like an Android library project.  Or am I
> mistaken and it also applies the android library plugin?
>
> Raymond
>
> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher <[hidden email]> wrote:
>>
>> + a colleague
>>
>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher <[hidden email]>
>> wrote:
>>>
>>> You can find that number like this:
>>> - x = number of externalNativeBuild.cmake.path in your build.gradle files
>>> - y = number of gradle configurations (like debug and release)
>>> - z = number of ABIs that you build
>>>
>>> The result is x * y * z. To be more accurate, you should consider y and z
>>> to be functions of each build.gradle file since these can vary.
>>>
>>> There is a second set of folders that hold the stripped versions of the
>>> .so files that is purely managed by the android gradle plugin, so you might
>>> consider the answer to be 2 * x * y * z.
>>>
>>> Hope this helps.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey <[hidden email]>
>>> wrote:
>>>>
>>>> This definitely a bit better, but still requires the boilerplate in
>>>> each leaf gradle file. But I can't seriously complain too much. I
>>>> think I'm more concerned with the implications this has underneath.
>>>> First, let me ask just to make sure I'm not misunderstanding: Does
>>>> each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR?
>>>> How many binary dirs do you manage internally and what determines when
>>>> they get created?
>>>>
>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher <[hidden email]>
>>>> wrote:
>>>> > Would it work for your scenario to provide properties in the root
>>>> > build.gradle:
>>>> >
>>>> > ext {
>>>> >     cmakePath = file "CMakeLists.txt"
>>>> > }
>>>> >
>>>> > And then consume them in the leaf app/build.gradle like this?
>>>> >
>>>> > externalNativeBuild {
>>>> >     cmake {
>>>> >         path cmakePath
>>>> >     }
>>>> > }
>>>> >
>>>> > It doesn't fully hide the details but it does centralize the
>>>> > information.
>>>> >
>>>> >
>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey
>>>> > <[hidden email]>
>>>> > wrote:
>>>> >>
>>>> >> I wouldn't want to do that, it's too convoluted. I have other
>>>> >> platforms that use these CMake scripts as well. For example, I run on
>>>> >> Windows and Linux platforms as well to build the native code. Normal
>>>> >> CMake behavior is designed to work at a root then go downwards to
>>>> >> find
>>>> >> targets. However it seems Gradle wants to start at a subdirectory and
>>>> >> work its way up to the root, which is opposite of CMake's intended
>>>> >> behavior IMHO. Not only that but I want to avoid special-casing
>>>> >> behavior in CMake just for Android's use.
>>>> >>
>>>> >> At the moment it feels like (again referring back to my previous
>>>> >> example structure) that both App2 and App3 each run CMake in
>>>> >> independent binary directories instead of sharing 1 binary directory
>>>> >> and building 2 targets inside of it. I prefer this behavior instead,
>>>> >> especially since it allows CMake to operate as it was intended. I
>>>> >> think it's a common case that projects will define multiple targets
>>>> >> starting from a single root, and expect multiple APKs or java
>>>> >> dependencies to be built within it.
>>>> >>
>>>> >> If I'm misunderstanding or making false assumptions please let me
>>>> >> know.
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher <[hidden email]>
>>>> >> wrote:
>>>> >> > Would it work for your situation for the leaf CMakeLists.txt to
>>>> >> > include
>>>> >> > the
>>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf
>>>> >> > CMakeLists.txt?
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey
>>>> >> > <[hidden email]>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >> Basically, yes. We have this sort of structure:
>>>> >> >>
>>>> >> >> <Root of git clone>/
>>>> >> >>     Applications/
>>>> >> >>         App1/
>>>> >> >>             build.gradle
>>>> >> >>             CMakeLists.txt
>>>> >> >>         App2/
>>>> >> >>             build.gradle
>>>> >> >>             CMakeLists.txt
>>>> >> >>         App3/
>>>> >> >>             build.gradle
>>>> >> >>             CMakeLists.txt
>>>> >> >>     CommonLib/
>>>> >> >>         build.gradle
>>>> >> >>         CMakeLists.txt
>>>> >> >>     CMakeLists.txt
>>>> >> >>
>>>> >> >> The libs are defined as follows:
>>>> >> >>
>>>> >> >> * CommonLib is a static library (java code builds into a library)
>>>> >> >>     * No dependencies of its own
>>>> >> >> * App1 is a shared library (java code builds into a library)
>>>> >> >>     * Dependencies (both java & native): CommonLib
>>>> >> >> * App2 is a shared library (java code builds into an APK)
>>>> >> >>    * Dependencies (both java & native): App1, CommonLib
>>>> >> >> * App3 is a shared library (java code builds into an APK)
>>>> >> >>    * Dependencies (both java & native): CommonLib
>>>> >> >>
>>>> >> >> In all cases, CMake must be invoked starting at the root
>>>> >> >> CMakeLists.txt 1 time. Each target can be built from the same
>>>> >> >> binary
>>>> >> >> directory after that. Previously with ANT, I was building all
>>>> >> >> native
>>>> >> >> targets first, then moved libs to appropriate directories so that
>>>> >> >> the
>>>> >> >> 'ant' command would package the libs.
>>>> >> >>
>>>> >> >> For gradle, I wanted to avoid redundantly specifying the root
>>>> >> >> directory in each leaf-level project directory. Using the example
>>>> >> >> above, the leaf-level directories in this case would be App1,
>>>> >> >> App2,
>>>> >> >> App3, and CommonLib. However I think we only specify the native
>>>> >> >> CMake
>>>> >> >> stuff for the java targets that actually output an APK (that would
>>>> >> >> be
>>>> >> >> App2 and App3 only).
>>>> >> >>
>>>> >> >> The ultimate goal is to specify stuff that doesn't change per
>>>> >> >> independent "module" of ours at the top level so it is transitive
>>>> >> >> /
>>>> >> >> inherited. Then only specify the differences (e.g. the native
>>>> >> >> CMake
>>>> >> >> target to build) in the leaf build gradle files. However you
>>>> >> >> indicated
>>>> >> >> this isn't possible.
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher
>>>> >> >> <[hidden email]>
>>>> >> >> wrote:
>>>> >> >> > What you're doing already sounds correct. You can't directly
>>>> >> >> > specify
>>>> >> >> > CMakeLists.txt from the top-level build.gradle. Recommendation
>>>> >> >> > is
>>>> >> >> > that
>>>> >> >> > it
>>>> >> >> > should be specified from the build.gradle of the module of the
>>>> >> >> > APK.
>>>> >> >> > Is
>>>> >> >> > the
>>>> >> >> > issue that you have multiple APK modules that all reference the
>>>> >> >> > same
>>>> >> >> > CMake
>>>> >> >> > libraries?
>>>> >> >> >
>>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey
>>>> >> >> > <[hidden email]>
>>>> >> >> > wrote:
>>>> >> >> >>
>>>> >> >> >> 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
>>>> >> >> >> <[hidden email]>
>>>> >> >> >> 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
>>>> >> >> >> > <[hidden email]>
>>>> >> >> >> > 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
>>>> >> >> >> >> <[hidden email]>
>>>> >> >> >> >> 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
>>>> >> >> >> >> > <[hidden email]>
>>>> >> >> >> >> > 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
>>>> >> >> >> >> >> <[hidden email]>
>>>> >> >> >> >> >> 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
>>>> >> >> >> >> >> > <[hidden email]>
>>>> >> >> >> >> >> > 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
12