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