Re: [CMake] CMake + Gradle for Android

I could probably do you one better, and just give you a stripped-down version of our repository. Basically, I'd remove all our C++ and Java source code but leave the CMake scripts and such intact somehow. It would take me some time to do this, though. Would this be helpful for you? In the

Re: [CMake] CMake + Gradle for Android

Hi again Robert, Would you be able to give me an estimate of how many APK projects you have, roughly which open source projects you reference via CMake add_subdirectories, and whether you have any variants beyond the default Debug and Release? If possible I'd like to approximate your project

Re: [CMake] CMake + Gradle for Android

Targets are specified per-Variation so they need to go under the variation-specific section. Probably something like this: defaultConfig { externalNativeBuild { cmake { targets "library1",

Re: [CMake] CMake + Gradle for Android

By the way when I try to use "targets", I get a failure. Basically Gradle doesn't recognize that keyword. I tried singular form as well ("target"), no luck. I'm running canary build of everything possible. What am I missing? On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher

Re: [CMake] CMake + Gradle for Android

Thanks for explaining, as usual your answers are making things much more clear. When it's all said and done and considering everything we've discussed up to this point, I'm fine with how you've architected the CMake integration with Gradle. I think the way things function is perfectly fine. My

Re: [CMake] CMake + Gradle for Android

On Thu, Aug 24, 2017 at 5:20 AM, Jom O'Fisher wrote: > We'll definitely be discussing this use case at our next C++ meeting and > I'll also be checking for myself whether ccache will work in this CMake > scenario. If ccache does work it seems like the natural level at which

Re: [CMake] CMake + Gradle for Android

By gradle module projects, I just mean the leaf build.gradle files as opposed to the root build.gradle. By configurations, I mean Build Types (debug vs release) and Product Flavors (demo vs free vs paid). Hereafter I will use the term "variant" rather than "configuration" to be precise. See this

Re: [CMake] CMake + Gradle for Android

I'm not sure what you mean by "gradle module projects", but maybe having some examples of what you mean by "configurations, C++ flags, etc" might make it more clear. Question: When specifying "path" for the CMakeLists.txt in the build.gradle file, how do you know which targets to build? For

Re: [CMake] CMake + Gradle for Android

Thanks for the write-up Robert. Having thought about it, I don't believe we have a satisfying answer at the gradle level for this kind of organization. In the gradle model module projects are the unit of organization for configurations, C/C++ flags, etc. and that's something we're pretty much

Re: [CMake] CMake + Gradle for Android

Another reason to reduce the number of binary directories is that there are different ways of managing third party libraries. One in particular that we use is to clone a repository into the binary directory and build all third party libs in real time based on a toolchain file (Similar to the

Re: [CMake] CMake + Gradle for Android

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

Re: [CMake] CMake + Gradle for Android

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

Re: [CMake] CMake + Gradle for Android

+ a colleague On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher 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

Re: [CMake] CMake + Gradle for Android

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

Re: [CMake] CMake + Gradle for Android

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`

Re: [CMake] CMake + Gradle for Android

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

Re: [CMake] CMake + Gradle for Android

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

Re: [CMake] CMake + Gradle for Android

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 wrote: > Basically, yes. We have this sort of structure: > >

Re: [CMake] CMake + Gradle for Android

Basically, yes. We have this sort of structure: / Applications/ App1/ build.gradle CMakeLists.txt App2/ build.gradle CMakeLists.txt App3/ build.gradle CMakeLists.txt CommonLib/

Re: [CMake] CMake + Gradle for Android

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

Re: [CMake] CMake + Gradle for Android

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

Re: [CMake] CMake + Gradle for Android

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

Re: [CMake] CMake + Gradle for Android

How exactly does Gradle package *.so files in an APK? I know that ANT used to do this for any libs under "libs/". 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

Re: [CMake] CMake + Gradle for Android

On 8/8/17, Jom O'Fisher 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 >

Re: [CMake] CMake + Gradle for Android

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

Re: [CMake] CMake + Gradle for Android

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

Re: [CMake] CMake + Gradle for Android

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:

Re: [CMake] CMake + Gradle for Android

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)

Re: [CMake] CMake + Gradle for Android

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