CMake + Gradle for Android

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
Loading...