<div dir="ltr">Targets are specified per-Variation so they need to go under the variation-specific section. Probably something like this:<div><br></div><div><div> defaultConfig {</div><div> externalNativeBuild {</div><div> cmake {</div><div> targets "library1", "library2"</div><div> }</div><div> }</div><div> }</div></div><div><br></div><div>That should work for you. Let me know.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 25, 2017 at 2:42 PM, Robert Dailey <span dir="ltr"><<a href="mailto:rcdailey.lists@gmail.com" target="_blank">rcdailey.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">By the way when I try to use "targets", I get a failure. Basically<br>
Gradle doesn't recognize that keyword. I tried singular form as well<br>
("target"), no luck.<br>
<br>
I'm running canary build of everything possible. What am I missing?<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher <<a href="mailto:jomofisher@gmail.com">jomofisher@gmail.com</a>> wrote:<br>
> By gradle module projects, I just mean the leaf build.gradle files as<br>
> opposed to the root build.gradle. By configurations, I mean Build Types<br>
> (debug vs release) and Product Flavors (demo vs free vs paid). Hereafter I<br>
> will use the term "variant" rather than "configuration" to be precise. See<br>
> this write-up on build variants:<br>
><br>
> <a href="https://developer.android.com/studio/build/build-variants.html#build-types" rel="noreferrer" target="_blank">https://developer.android.com/<wbr>studio/build/build-variants.<wbr>html#build-types</a><br>
><br>
> This build matrix is constructed at the leaf build.gradle level. Native<br>
> build in gradle allows you to set C/C++ flags individually for each variant<br>
> so that you can define compiler flags (for example, -DFREE_VERSION).<br>
><br>
> One thing to notice at this stage is that the same CMake target may be built<br>
> with different compiler flags across different projects, build types, and<br>
> product flavors. So in the general case, build outputs won't be the same.<br>
><br>
> You asked which targets build when specifying path. By default, we build all<br>
> targets that produce an .so. You can override this by setting<br>
> externalNativeBuild.cmake.<wbr>targets. For example,<br>
><br>
> paid {<br>
> ...<br>
> externalNativeBuild {<br>
> cmake {<br>
> ...<br>
> targets "native-lib-paid"<br>
> }<br>
> }<br>
> }<br>
><br>
> As for your last question, the model we generally see used is that the main<br>
> CMakeLists.txt is next to the leaf build.gradle such that this<br>
> CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt (though<br>
> they may share common dependencies and settings). Otherwise, multiple APK<br>
> projects would perform pretty much similar to yours--they would build<br>
> targets per-leaf project and not share build outputs. As far as I can see<br>
> your organization is just as valid so long as you only build the targets you<br>
> need.<br>
><br>
> Regarding native dependencies between java projects. We generally try to<br>
> avoid making the CMake build depend on the gradle build (you should be able<br>
> to replicate the CMake build from the command-line if you set the right<br>
> flags). At the moment I don't see a way we could make things better without<br>
> violating that tenet but that could be lack of imagination on my part.<br>
><br>
> We'll definitely be discussing this use case at our next C++ meeting and<br>
> I'll also be checking for myself whether ccache will work in this CMake<br>
> scenario. If ccache does work it seems like the natural level at which to<br>
> fold identical builds.<br>
><br>
><br>
><br>
> On Wed, Aug 23, 2017 at 1:03 PM, Robert Dailey <<a href="mailto:rcdailey.lists@gmail.com">rcdailey.lists@gmail.com</a>><br>
> wrote:<br>
>><br>
>> I'm not sure what you mean by "gradle module projects", but maybe<br>
>> having some examples of what you mean by "configurations, C++ flags,<br>
>> etc" might make it more clear.<br>
>><br>
>> Question: When specifying "path" for the CMakeLists.txt in the<br>
>> build.gradle file, how do you know which targets to build? For<br>
>> example, that run of CMake may generate 100 targets, but only 20 need<br>
>> to build and be packaged (*.so files) with the APK. Do you just build<br>
>> "all"? Is there a way to specify the target itself?<br>
>><br>
>> Thanks again. I'd still like to know more about what the ideal<br>
>> organization is. I find it hard to believe that large android projects<br>
>> rarely break things up into multiple, separate "components" that are<br>
>> built independently. That's really the gist of what we're dealing with<br>
>> here. Your typical "hello world" project likely will have only 1<br>
>> CMakeLists.txt that is pretty self-contained, but all the<br>
>> documentation I've looked at so far doesn't show the best way to<br>
>> handle native library dependencies across java projects between<br>
>> build.gradle files (or maybe I'm just not looking hard enough).<br>
>><br>
>> On Wed, Aug 23, 2017 at 1:02 PM, Jom O'Fisher <<a href="mailto:jomofisher@gmail.com">jomofisher@gmail.com</a>><br>
>> wrote:<br>
>> > Thanks for the write-up Robert. Having thought about it, I don't believe<br>
>> > we<br>
>> > have a satisfying answer at the gradle level for this kind of<br>
>> > organization.<br>
>> > In the gradle model module projects are the unit of organization for<br>
>> > configurations, C/C++ flags, etc. and that's something we're pretty much<br>
>> > stuck with.<br>
>> > Regarding just the redundant build issue, would something like ccache<br>
>> > help?<br>
>> > I know people have used it with ndk-build with success, I'm not sure<br>
>> > about<br>
>> > CMake but I don't see why that should make a difference.<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Tue, Aug 22, 2017 at 10:27 AM, Robert Dailey<br>
>> > <<a href="mailto:rcdailey.lists@gmail.com">rcdailey.lists@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Another reason to reduce the number of binary directories is that<br>
>> >> there are different ways of managing third party libraries. One in<br>
>> >> particular that we use is to clone a repository into the binary<br>
>> >> directory and build all third party libs in real time based on a<br>
>> >> toolchain file (Similar to the functionality provided by<br>
>> >> ExternalProject module in CMake). This is repeated from scratch only<br>
>> >> if the work hasn't already been done in the binary directory before.<br>
>> >> By having more binary dirs than needed, this work is being done an<br>
>> >> exponential amount of times which can result in a lot of wasted time<br>
>> >> waiting. There are 1 time operations that multiple targets can benefit<br>
>> >> from in a single binary tree, instead of 1 per unique target being<br>
>> >> invoked.<br>
>> >><br>
>> >> Sorry to keep responding: I'm just thinking of things as I go and<br>
>> >> bringing them up, to shed light on some of the reasoning behind my<br>
>> >> suggestions.<br>
>> >><br>
>> >> On Tue, Aug 22, 2017 at 9:26 AM, Robert Dailey<br>
>> >> <<a href="mailto:rcdailey.lists@gmail.com">rcdailey.lists@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > Sorry I forgot to answer your last set of questions:<br>
>> >> ><br>
>> >> > CommonLib is indeed 2 things:<br>
>> >> ><br>
>> >> > * A common (static or shared) library for native code (most of our<br>
>> >> > CMake targets specify CommonLib as a link dependency)<br>
>> >> > * A common library for Java code (we do specify this as a dependency<br>
>> >> > for most java targets in Gradle, specifically those under<br>
>> >> > Applications/)<br>
>> >> ><br>
>> >> > On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu <<a href="mailto:chiur@google.com">chiur@google.com</a>><br>
>> >> > wrote:<br>
>> >> >> Hi Robert,<br>
>> >> >><br>
>> >> >> I work with Jom on the Android Studio team, and I would like to<br>
>> >> >> clarify<br>
>> >> >> a<br>
>> >> >> few things to better understand your situation.<br>
>> >> >> You mentioned the project is intend to be cross platform. Normally,<br>
>> >> >> in<br>
>> >> >> such<br>
>> >> >> situation, we expect there to be a single CMake root project to be<br>
>> >> >> imported<br>
>> >> >> into one of the Android library/application. However, in your case,<br>
>> >> >> there<br>
>> >> >> are subprojects with Java code.<br>
>> >> >><br>
>> >> >> Are the CMake code in App1/2/3 intended to be cross platform too?<br>
>> >> >> Or<br>
>> >> >> are<br>
>> >> >> they Android specific code? If they are meant to be cross platform,<br>
>> >> >> how<br>
>> >> >> does the Java code works on other platforms? Or perhaps you added<br>
>> >> >> Java<br>
>> >> >> binding in those subprojects just for Android?<br>
>> >> >><br>
>> >> >> The build.gradle in CommonLib, what kind of Gradle project is that?<br>
>> >> >> From<br>
>> >> >> your description, it doesn't look like an Android library project.<br>
>> >> >> Or<br>
>> >> >> am I<br>
>> >> >> mistaken and it also applies the android library plugin?<br>
>> >> >><br>
>> >> >> Raymond<br>
>> >> >><br>
>> >> >> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher <<a href="mailto:jomofisher@gmail.com">jomofisher@gmail.com</a>><br>
>> >> >> wrote:<br>
>> >> >>><br>
>> >> >>> + a colleague<br>
>> >> >>><br>
>> >> >>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher<br>
>> >> >>> <<a href="mailto:jomofisher@gmail.com">jomofisher@gmail.com</a>><br>
>> >> >>> wrote:<br>
>> >> >>>><br>
>> >> >>>> You can find that number like this:<br>
>> >> >>>> - x = number of externalNativeBuild.cmake.path in your<br>
>> >> >>>> build.gradle<br>
>> >> >>>> files<br>
>> >> >>>> - y = number of gradle configurations (like debug and release)<br>
>> >> >>>> - z = number of ABIs that you build<br>
>> >> >>>><br>
>> >> >>>> The result is x * y * z. To be more accurate, you should consider<br>
>> >> >>>> y<br>
>> >> >>>> and z<br>
>> >> >>>> to be functions of each build.gradle file since these can vary.<br>
>> >> >>>><br>
>> >> >>>> There is a second set of folders that hold the stripped versions<br>
>> >> >>>> of<br>
>> >> >>>> the<br>
>> >> >>>> .so files that is purely managed by the android gradle plugin, so<br>
>> >> >>>> you<br>
>> >> >>>> might<br>
>> >> >>>> consider the answer to be 2 * x * y * z.<br>
>> >> >>>><br>
>> >> >>>> Hope this helps.<br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey<br>
>> >> >>>> <<a href="mailto:rcdailey.lists@gmail.com">rcdailey.lists@gmail.com</a>><br>
>> >> >>>> wrote:<br>
>> >> >>>>><br>
>> >> >>>>> This definitely a bit better, but still requires the boilerplate<br>
>> >> >>>>> in<br>
>> >> >>>>> each leaf gradle file. But I can't seriously complain too much. I<br>
>> >> >>>>> think I'm more concerned with the implications this has<br>
>> >> >>>>> underneath.<br>
>> >> >>>>> First, let me ask just to make sure I'm not misunderstanding:<br>
>> >> >>>>> Does<br>
>> >> >>>>> each `externalNativeBuild` entry essentially mean 1<br>
>> >> >>>>> CMAKE_BINARY_DIR?<br>
>> >> >>>>> How many binary dirs do you manage internally and what determines<br>
>> >> >>>>> when<br>
>> >> >>>>> they get created?<br>
>> >> >>>>><br>
>> >> >>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher<br>
>> >> >>>>> <<a href="mailto:jomofisher@gmail.com">jomofisher@gmail.com</a>><br>
>> >> >>>>> wrote:<br>
>> >> >>>>> > Would it work for your scenario to provide properties in the<br>
>> >> >>>>> > root<br>
>> >> >>>>> > build.gradle:<br>
>> >> >>>>> ><br>
>> >> >>>>> > ext {<br>
>> >> >>>>> > cmakePath = file "CMakeLists.txt"<br>
>> >> >>>>> > }<br>
>> >> >>>>> ><br>
>> >> >>>>> > And then consume them in the leaf app/build.gradle like this?<br>
>> >> >>>>> ><br>
>> >> >>>>> > externalNativeBuild {<br>
>> >> >>>>> > cmake {<br>
>> >> >>>>> > path cmakePath<br>
>> >> >>>>> > }<br>
>> >> >>>>> > }<br>
>> >> >>>>> ><br>
>> >> >>>>> > It doesn't fully hide the details but it does centralize the<br>
>> >> >>>>> > information.<br>
>> >> >>>>> ><br>
>> >> >>>>> ><br>
>> >> >>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey<br>
>> >> >>>>> > <<a href="mailto:rcdailey.lists@gmail.com">rcdailey.lists@gmail.com</a>><br>
>> >> >>>>> > wrote:<br>
>> >> >>>>> >><br>
>> >> >>>>> >> I wouldn't want to do that, it's too convoluted. I have other<br>
>> >> >>>>> >> platforms that use these CMake scripts as well. For example, I<br>
>> >> >>>>> >> run on<br>
>> >> >>>>> >> Windows and Linux platforms as well to build the native code.<br>
>> >> >>>>> >> Normal<br>
>> >> >>>>> >> CMake behavior is designed to work at a root then go downwards<br>
>> >> >>>>> >> to<br>
>> >> >>>>> >> find<br>
>> >> >>>>> >> targets. However it seems Gradle wants to start at a<br>
>> >> >>>>> >> subdirectory<br>
>> >> >>>>> >> and<br>
>> >> >>>>> >> work its way up to the root, which is opposite of CMake's<br>
>> >> >>>>> >> intended<br>
>> >> >>>>> >> behavior IMHO. Not only that but I want to avoid<br>
>> >> >>>>> >> special-casing<br>
>> >> >>>>> >> behavior in CMake just for Android's use.<br>
>> >> >>>>> >><br>
>> >> >>>>> >> At the moment it feels like (again referring back to my<br>
>> >> >>>>> >> previous<br>
>> >> >>>>> >> example structure) that both App2 and App3 each run CMake in<br>
>> >> >>>>> >> independent binary directories instead of sharing 1 binary<br>
>> >> >>>>> >> directory<br>
>> >> >>>>> >> and building 2 targets inside of it. I prefer this behavior<br>
>> >> >>>>> >> instead,<br>
>> >> >>>>> >> especially since it allows CMake to operate as it was<br>
>> >> >>>>> >> intended. I<br>
>> >> >>>>> >> think it's a common case that projects will define multiple<br>
>> >> >>>>> >> targets<br>
>> >> >>>>> >> starting from a single root, and expect multiple APKs or java<br>
>> >> >>>>> >> dependencies to be built within it.<br>
>> >> >>>>> >><br>
>> >> >>>>> >> If I'm misunderstanding or making false assumptions please let<br>
>> >> >>>>> >> me<br>
>> >> >>>>> >> know.<br>
>> >> >>>>> >><br>
>> >> >>>>> >><br>
>> >> >>>>> >><br>
>> >> >>>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher<br>
>> >> >>>>> >> <<a href="mailto:jomofisher@gmail.com">jomofisher@gmail.com</a>><br>
>> >> >>>>> >> wrote:<br>
>> >> >>>>> >> > Would it work for your situation for the leaf CMakeLists.txt<br>
>> >> >>>>> >> > to<br>
>> >> >>>>> >> > include<br>
>> >> >>>>> >> > the<br>
>> >> >>>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in<br>
>> >> >>>>> >> > the<br>
>> >> >>>>> >> > leaf<br>
>> >> >>>>> >> > CMakeLists.txt?<br>
>> >> >>>>> >> ><br>
>> >> >>>>> >> ><br>
>> >> >>>>> >> ><br>
>> >> >>>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey<br>
>> >> >>>>> >> > <<a href="mailto:rcdailey.lists@gmail.com">rcdailey.lists@gmail.com</a>><br>
>> >> >>>>> >> > wrote:<br>
>> >> >>>>> >> >><br>
>> >> >>>>> >> >> Basically, yes. We have this sort of structure:<br>
>> >> >>>>> >> >><br>
>> >> >>>>> >> >> <Root of git clone>/<br>
>> >> >>>>> >> >> Applications/<br>
>> >> >>>>> >> >> App1/<br>
>> >> >>>>> >> >> build.gradle<br>
>> >> >>>>> >> >> CMakeLists.txt<br>
>> >> >>>>> >> >> App2/<br>
>> >> >>>>> >> >> build.gradle<br>
>> >> >>>>> >> >> CMakeLists.txt<br>
>> >> >>>>> >> >> App3/<br>
>> >> >>>>> >> >> build.gradle<br>
>> >> >>>>> >> >> CMakeLists.txt<br>
>> >> >>>>> >> >> CommonLib/<br>
>> >> >>>>> >> >> build.gradle<br>
>> >> >>>>> >> >> CMakeLists.txt<br>
>> >> >>>>> >> >> CMakeLists.txt<br>
>> >> >>>>> >> >><br>
>> >> >>>>> >> >> The libs are defined as follows:<br>
>> >> >>>>> >> >><br>
>> >> >>>>> >> >> * CommonLib is a static library (java code builds into a<br>
>> >> >>>>> >> >> library)<br>
>> >> >>>>> >> >> * No dependencies of its own<br>
>> >> >>>>> >> >> * App1 is a shared library (java code builds into a<br>
>> >> >>>>> >> >> library)<br>
>> >> >>>>> >> >> * Dependencies (both java & native): CommonLib<br>
>> >> >>>>> >> >> * App2 is a shared library (java code builds into an APK)<br>
>> >> >>>>> >> >> * Dependencies (both java & native): App1, CommonLib<br>
>> >> >>>>> >> >> * App3 is a shared library (java code builds into an APK)<br>
>> >> >>>>> >> >> * Dependencies (both java & native): CommonLib<br>
>> >> >>>>> >> >><br>
>> >> >>>>> >> >> In all cases, CMake must be invoked starting at the root<br>
>> >> >>>>> >> >> CMakeLists.txt 1 time. Each target can be built from the<br>
>> >> >>>>> >> >> same<br>
>> >> >>>>> >> >> binary<br>
>> >> >>>>> >> >> directory after that. Previously with ANT, I was building<br>
>> >> >>>>> >> >> all<br>
>> >> >>>>> >> >> native<br>
>> >> >>>>> >> >> targets first, then moved libs to appropriate directories<br>
>> >> >>>>> >> >> so<br>
>> >> >>>>> >> >> that<br>
>> >> >>>>> >> >> the<br>
>> >> >>>>> >> >> 'ant' command would package the libs.<br>
>> >> >>>>> >> >><br>
>> >> >>>>> >> >> For gradle, I wanted to avoid redundantly specifying the<br>
>> >> >>>>> >> >> root<br>
>> >> >>>>> >> >> directory in each leaf-level project directory. Using the<br>
>> >> >>>>> >> >> example<br>
>> >> >>>>> >> >> above, the leaf-level directories in this case would be<br>
>> >> >>>>> >> >> App1,<br>
>> >> >>>>> >> >> App2,<br>
>> >> >>>>> >> >> App3, and CommonLib. However I think we only specify the<br>
>> >> >>>>> >> >> native<br>
>> >> >>>>> >> >> CMake<br>
>> >> >>>>> >> >> stuff for the java targets that actually output an APK<br>
>> >> >>>>> >> >> (that<br>
>> >> >>>>> >> >> would<br>
>> >> >>>>> >> >> be<br>
>> >> >>>>> >> >> App2 and App3 only).<br>
>> >> >>>>> >> >><br>
>> >> >>>>> >> >> The ultimate goal is to specify stuff that doesn't change<br>
>> >> >>>>> >> >> per<br>
>> >> >>>>> >> >> independent "module" of ours at the top level so it is<br>
>> >> >>>>> >> >> transitive<br>
>> >> >>>>> >> >> /<br>
>> >> >>>>> >> >> inherited. Then only specify the differences (e.g. the<br>
>> >> >>>>> >> >> native<br>
>> >> >>>>> >> >> CMake<br>
>> >> >>>>> >> >> target to build) in the leaf build gradle files. However<br>
>> >> >>>>> >> >> you<br>
>> >> >>>>> >> >> indicated<br>
>> >> >>>>> >> >> this isn't possible.<br>
>> >> >>>>> >> >><br>
>> >> >>>>> >> >><br>
>> >> >>>>> >> >><br>
>> >> >>>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher<br>
>> >> >>>>> >> >> <<a href="mailto:jomofisher@gmail.com">jomofisher@gmail.com</a>><br>
>> >> >>>>> >> >> wrote:<br>
>> >> >>>>> >> >> > What you're doing already sounds correct. You can't<br>
>> >> >>>>> >> >> > directly<br>
>> >> >>>>> >> >> > specify<br>
>> >> >>>>> >> >> > CMakeLists.txt from the top-level build.gradle.<br>
>> >> >>>>> >> >> > Recommendation<br>
>> >> >>>>> >> >> > is<br>
>> >> >>>>> >> >> > that<br>
>> >> >>>>> >> >> > it<br>
>> >> >>>>> >> >> > should be specified from the build.gradle of the module<br>
>> >> >>>>> >> >> > of<br>
>> >> >>>>> >> >> > the<br>
>> >> >>>>> >> >> > APK.<br>
>> >> >>>>> >> >> > Is<br>
>> >> >>>>> >> >> > the<br>
>> >> >>>>> >> >> > issue that you have multiple APK modules that all<br>
>> >> >>>>> >> >> > reference<br>
>> >> >>>>> >> >> > the<br>
>> >> >>>>> >> >> > same<br>
>> >> >>>>> >> >> > CMake<br>
>> >> >>>>> >> >> > libraries?<br>
>> >> >>>>> >> >> ><br>
>> >> >>>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey<br>
>> >> >>>>> >> >> > <<a href="mailto:rcdailey.lists@gmail.com">rcdailey.lists@gmail.com</a>><br>
>> >> >>>>> >> >> > wrote:<br>
>> >> >>>>> >> >> >><br>
>> >> >>>>> >> >> >> Thanks this is very helpful. The other question I have<br>
>> >> >>>>> >> >> >> is:<br>
>> >> >>>>> >> >> >> Is<br>
>> >> >>>>> >> >> >> there<br>
>> >> >>>>> >> >> >> a<br>
>> >> >>>>> >> >> >> place to centrally specify the root CMakeLists.txt?<br>
>> >> >>>>> >> >> >> Basically,<br>
>> >> >>>>> >> >> >> I<br>
>> >> >>>>> >> >> >> want<br>
>> >> >>>>> >> >> >> to specify the CMake root in 1 place, and have targets<br>
>> >> >>>>> >> >> >> (defined<br>
>> >> >>>>> >> >> >> further down in subdirectories) that require APK<br>
>> >> >>>>> >> >> >> packaging<br>
>> >> >>>>> >> >> >> to<br>
>> >> >>>>> >> >> >> specify<br>
>> >> >>>>> >> >> >> only the native target name that should be built &<br>
>> >> >>>>> >> >> >> packaged.<br>
>> >> >>>>> >> >> >><br>
>> >> >>>>> >> >> >> At the moment we specify the root CMakeLists.txt by<br>
>> >> >>>>> >> >> >> walking<br>
>> >> >>>>> >> >> >> up<br>
>> >> >>>>> >> >> >> the<br>
>> >> >>>>> >> >> >> tree, paths like "../../../../CMakeLists.txt". I think<br>
>> >> >>>>> >> >> >> this<br>
>> >> >>>>> >> >> >> should<br>
>> >> >>>>> >> >> >> be<br>
>> >> >>>>> >> >> >> put at the top-level build gradle file if possible. Is<br>
>> >> >>>>> >> >> >> this<br>
>> >> >>>>> >> >> >> doable<br>
>> >> >>>>> >> >> >> at<br>
>> >> >>>>> >> >> >> the moment? What is the recommended setup?<br>
>> >> >>>>> >> >> >><br>
>> >> >>>>> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher<br>
>> >> >>>>> >> >> >> <<a href="mailto:jomofisher@gmail.com">jomofisher@gmail.com</a>><br>
>> >> >>>>> >> >> >> wrote:<br>
>> >> >>>>> >> >> >> > Gradle does introspection on the CMake build to find<br>
>> >> >>>>> >> >> >> > .so<br>
>> >> >>>>> >> >> >> > targets<br>
>> >> >>>>> >> >> >> > and<br>
>> >> >>>>> >> >> >> > those<br>
>> >> >>>>> >> >> >> > get packaged.<br>
>> >> >>>>> >> >> >> > There is also a special case for stl/runtime .so files<br>
>> >> >>>>> >> >> >> > from<br>
>> >> >>>>> >> >> >> > the<br>
>> >> >>>>> >> >> >> > NDK.<br>
>> >> >>>>> >> >> >> > Any additional .so files need to specified in<br>
>> >> >>>>> >> >> >> > build.gradle<br>
>> >> >>>>> >> >> >> > using<br>
>> >> >>>>> >> >> >> > jniDirs<br>
>> >> >>>>> >> >> >> ><br>
>> >> >>>>> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey<br>
>> >> >>>>> >> >> >> > <<a href="mailto:rcdailey.lists@gmail.com">rcdailey.lists@gmail.com</a>><br>
>> >> >>>>> >> >> >> > wrote:<br>
>> >> >>>>> >> >> >> >><br>
>> >> >>>>> >> >> >> >> How exactly does Gradle package *.so files in an APK?<br>
>> >> >>>>> >> >> >> >> I<br>
>> >> >>>>> >> >> >> >> know<br>
>> >> >>>>> >> >> >> >> that<br>
>> >> >>>>> >> >> >> >> ANT<br>
>> >> >>>>> >> >> >> >> used to do this for any libs under "libs/<ABI>". Does<br>
>> >> >>>>> >> >> >> >> Gradle<br>
>> >> >>>>> >> >> >> >> do<br>
>> >> >>>>> >> >> >> >> some<br>
>> >> >>>>> >> >> >> >> introspection into CMake targets to see if outputs<br>
>> >> >>>>> >> >> >> >> are<br>
>> >> >>>>> >> >> >> >> *.so,<br>
>> >> >>>>> >> >> >> >> and<br>
>> >> >>>>> >> >> >> >> copy<br>
>> >> >>>>> >> >> >> >> those to some location if needed? What about<br>
>> >> >>>>> >> >> >> >> libraries<br>
>> >> >>>>> >> >> >> >> like<br>
>> >> >>>>> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd like<br>
>> >> >>>>> >> >> >> >> to<br>
>> >> >>>>> >> >> >> >> know<br>
>> >> >>>>> >> >> >> >> if<br>
>> >> >>>>> >> >> >> >> any<br>
>> >> >>>>> >> >> >> >> manual copy steps are needed in CMake to put outputs<br>
>> >> >>>>> >> >> >> >> in<br>
>> >> >>>>> >> >> >> >> proper<br>
>> >> >>>>> >> >> >> >> locations for the APK build step. I had to do this<br>
>> >> >>>>> >> >> >> >> when<br>
>> >> >>>>> >> >> >> >> using<br>
>> >> >>>>> >> >> >> >> ANT.<br>
>> >> >>>>> >> >> >> >><br>
>> >> >>>>> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher<br>
>> >> >>>>> >> >> >> >> <<a href="mailto:jomofisher@gmail.com">jomofisher@gmail.com</a>><br>
>> >> >>>>> >> >> >> >> wrote:<br>
>> >> >>>>> >> >> >> >> > 1) There is a folder created for each ABI under the<br>
>> >> >>>>> >> >> >> >> > project<br>
>> >> >>>>> >> >> >> >> > module<br>
>> >> >>>>> >> >> >> >> > folder<br>
>> >> >>>>> >> >> >> >> > (so unique per module per ABI)<br>
>> >> >>>>> >> >> >> >> > 2) Gradle doesn't specify language level though you<br>
>> >> >>>>> >> >> >> >> > can<br>
>> >> >>>>> >> >> >> >> > choose<br>
>> >> >>>>> >> >> >> >> > to<br>
>> >> >>>>> >> >> >> >> > specify it<br>
>> >> >>>>> >> >> >> >> > yourself from the build.gradle. This doc does a<br>
>> >> >>>>> >> >> >> >> > pretty<br>
>> >> >>>>> >> >> >> >> > good job<br>
>> >> >>>>> >> >> >> >> > of<br>
>> >> >>>>> >> >> >> >> > explaining which variables are set by Gradle:<br>
>> >> >>>>> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> > <a href="https://developer.android.com/ndk/guides/cmake.html#variables" rel="noreferrer" target="_blank">https://developer.android.com/<wbr>ndk/guides/cmake.html#<wbr>variables</a>.<br>
>> >> >>>>> >> >> >> >> > Philosophically, we try to set as little as we can<br>
>> >> >>>>> >> >> >> >> > get<br>
>> >> >>>>> >> >> >> >> > away<br>
>> >> >>>>> >> >> >> >> > with.<br>
>> >> >>>>> >> >> >> >> > In<br>
>> >> >>>>> >> >> >> >> > particular, the section titled "Understanding the<br>
>> >> >>>>> >> >> >> >> > CMake<br>
>> >> >>>>> >> >> >> >> > build<br>
>> >> >>>>> >> >> >> >> > command"<br>
>> >> >>>>> >> >> >> >> > lays<br>
>> >> >>>>> >> >> >> >> > out exactly what we set. You can also see the<br>
>> >> >>>>> >> >> >> >> > folders<br>
>> >> >>>>> >> >> >> >> > we<br>
>> >> >>>>> >> >> >> >> > specify<br>
>> >> >>>>> >> >> >> >> > (one<br>
>> >> >>>>> >> >> >> >> > per<br>
>> >> >>>>> >> >> >> >> > module per ABI)<br>
>> >> >>>>> >> >> >> >> > 3) Not sure I understand this.<br>
>> >> >>>>> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> > The other document worth taking a look at (if you<br>
>> >> >>>>> >> >> >> >> > haven't<br>
>> >> >>>>> >> >> >> >> > already)<br>
>> >> >>>>> >> >> >> >> > is:<br>
>> >> >>>>> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> > <a href="https://developer.android.com/studio/projects/add-native-code.html" rel="noreferrer" target="_blank">https://developer.android.com/<wbr>studio/projects/add-native-<wbr>code.html</a><br>
>> >> >>>>> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey<br>
>> >> >>>>> >> >> >> >> > <<a href="mailto:rcdailey.lists@gmail.com">rcdailey.lists@gmail.com</a>><br>
>> >> >>>>> >> >> >> >> > wrote:<br>
>> >> >>>>> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> Thanks Jom<br>
>> >> >>>>> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> Honestly, I prefer option 1 to work simply because<br>
>> >> >>>>> >> >> >> >> >> that's<br>
>> >> >>>>> >> >> >> >> >> how<br>
>> >> >>>>> >> >> >> >> >> Google's<br>
>> >> >>>>> >> >> >> >> >> officially supporting CMake. But it also has<br>
>> >> >>>>> >> >> >> >> >> debugging<br>
>> >> >>>>> >> >> >> >> >> which<br>
>> >> >>>>> >> >> >> >> >> is<br>
>> >> >>>>> >> >> >> >> >> the<br>
>> >> >>>>> >> >> >> >> >> #1<br>
>> >> >>>>> >> >> >> >> >> reason for me.<br>
>> >> >>>>> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> However, I'd like to understand a lot more about<br>
>> >> >>>>> >> >> >> >> >> how<br>
>> >> >>>>> >> >> >> >> >> the<br>
>> >> >>>>> >> >> >> >> >> integration<br>
>> >> >>>>> >> >> >> >> >> really happens. For example, I have these<br>
>> >> >>>>> >> >> >> >> >> questions:<br>
>> >> >>>>> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> 1) How, internally, are CMake build directories<br>
>> >> >>>>> >> >> >> >> >> managed?<br>
>> >> >>>>> >> >> >> >> >> Do<br>
>> >> >>>>> >> >> >> >> >> you<br>
>> >> >>>>> >> >> >> >> >> generate 1 per unique android project? What about<br>
>> >> >>>>> >> >> >> >> >> for<br>
>> >> >>>>> >> >> >> >> >> each<br>
>> >> >>>>> >> >> >> >> >> specific<br>
>> >> >>>>> >> >> >> >> >> platform (x86, armeabi-v7a, etc)?<br>
>> >> >>>>> >> >> >> >> >> 2) Last time I looked into CMake integration,<br>
>> >> >>>>> >> >> >> >> >> things<br>
>> >> >>>>> >> >> >> >> >> defined<br>
>> >> >>>>> >> >> >> >> >> inside<br>
>> >> >>>>> >> >> >> >> >> the CMake scripts were ignored because they are<br>
>> >> >>>>> >> >> >> >> >> specified<br>
>> >> >>>>> >> >> >> >> >> at<br>
>> >> >>>>> >> >> >> >> >> the<br>
>> >> >>>>> >> >> >> >> >> command line. Namely, all of those settings that<br>
>> >> >>>>> >> >> >> >> >> are<br>
>> >> >>>>> >> >> >> >> >> driven by<br>
>> >> >>>>> >> >> >> >> >> the<br>
>> >> >>>>> >> >> >> >> >> Gradle configuration (CXX language level was one<br>
>> >> >>>>> >> >> >> >> >> in<br>
>> >> >>>>> >> >> >> >> >> particular<br>
>> >> >>>>> >> >> >> >> >> I<br>
>> >> >>>>> >> >> >> >> >> think; I specify C++14 support via CMake, but I<br>
>> >> >>>>> >> >> >> >> >> recall<br>
>> >> >>>>> >> >> >> >> >> this<br>
>> >> >>>>> >> >> >> >> >> being<br>
>> >> >>>>> >> >> >> >> >> overridden from outside)?<br>
>> >> >>>>> >> >> >> >> >> 3) How redundant is it to configure individual<br>
>> >> >>>>> >> >> >> >> >> libraries<br>
>> >> >>>>> >> >> >> >> >> via<br>
>> >> >>>>> >> >> >> >> >> the<br>
>> >> >>>>> >> >> >> >> >> gradle scripts? In my previous attempts, I wanted<br>
>> >> >>>>> >> >> >> >> >> to<br>
>> >> >>>>> >> >> >> >> >> define<br>
>> >> >>>>> >> >> >> >> >> common<br>
>> >> >>>>> >> >> >> >> >> stuff for CMake / native code at the root gradle<br>
>> >> >>>>> >> >> >> >> >> or<br>
>> >> >>>>> >> >> >> >> >> settings<br>
>> >> >>>>> >> >> >> >> >> file,<br>
>> >> >>>>> >> >> >> >> >> and<br>
>> >> >>>>> >> >> >> >> >> only define the differences in the actual gradle<br>
>> >> >>>>> >> >> >> >> >> build<br>
>> >> >>>>> >> >> >> >> >> files<br>
>> >> >>>>> >> >> >> >> >> for<br>
>> >> >>>>> >> >> >> >> >> each<br>
>> >> >>>>> >> >> >> >> >> corresponding Java target (like, defining the name<br>
>> >> >>>>> >> >> >> >> >> of<br>
>> >> >>>>> >> >> >> >> >> the<br>
>> >> >>>>> >> >> >> >> >> native<br>
>> >> >>>>> >> >> >> >> >> (shared library) target in Gradle, but the command<br>
>> >> >>>>> >> >> >> >> >> line<br>
>> >> >>>>> >> >> >> >> >> invocation,<br>
>> >> >>>>> >> >> >> >> >> -D<br>
>> >> >>>>> >> >> >> >> >> CMake settings, etc would all be common and<br>
>> >> >>>>> >> >> >> >> >> defined<br>
>> >> >>>>> >> >> >> >> >> at<br>
>> >> >>>>> >> >> >> >> >> the<br>
>> >> >>>>> >> >> >> >> >> root).<br>
>> >> >>>>> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way<br>
>> >> >>>>> >> >> >> >> >> of<br>
>> >> >>>>> >> >> >> >> >> doing<br>
>> >> >>>>> >> >> >> >> >> things<br>
>> >> >>>>> >> >> >> >> >> and<br>
>> >> >>>>> >> >> >> >> >> keep CMake-related settings self-contained to the<br>
>> >> >>>>> >> >> >> >> >> CMake<br>
>> >> >>>>> >> >> >> >> >> scripts<br>
>> >> >>>>> >> >> >> >> >> themselves, the better. This also makes<br>
>> >> >>>>> >> >> >> >> >> cross-platform<br>
>> >> >>>>> >> >> >> >> >> easier<br>
>> >> >>>>> >> >> >> >> >> (we<br>
>> >> >>>>> >> >> >> >> >> build the native code in Windows, for example, so<br>
>> >> >>>>> >> >> >> >> >> having<br>
>> >> >>>>> >> >> >> >> >> settings<br>
>> >> >>>>> >> >> >> >> >> specified in the gradle files do not carry over to<br>
>> >> >>>>> >> >> >> >> >> other<br>
>> >> >>>>> >> >> >> >> >> platforms.<br>
>> >> >>>>> >> >> >> >> >> Namely, settings that are not platform specific<br>
>> >> >>>>> >> >> >> >> >> like<br>
>> >> >>>>> >> >> >> >> >> the<br>
>> >> >>>>> >> >> >> >> >> C++<br>
>> >> >>>>> >> >> >> >> >> language<br>
>> >> >>>>> >> >> >> >> >> level).<br>
>> >> >>>>> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> If there's a detailed document / wiki I can read<br>
>> >> >>>>> >> >> >> >> >> on<br>
>> >> >>>>> >> >> >> >> >> the<br>
>> >> >>>>> >> >> >> >> >> intrinsics<br>
>> >> >>>>> >> >> >> >> >> of<br>
>> >> >>>>> >> >> >> >> >> CMake integration in Gradle / Android Studio, I'd<br>
>> >> >>>>> >> >> >> >> >> love to<br>
>> >> >>>>> >> >> >> >> >> read<br>
>> >> >>>>> >> >> >> >> >> it.<br>
>> >> >>>>> >> >> >> >> >> Otherwise, I hope you won't mind if I pick your<br>
>> >> >>>>> >> >> >> >> >> brain<br>
>> >> >>>>> >> >> >> >> >> as<br>
>> >> >>>>> >> >> >> >> >> questions<br>
>> >> >>>>> >> >> >> >> >> come up. I think I'm going to try option 1 for now<br>
>> >> >>>>> >> >> >> >> >> and<br>
>> >> >>>>> >> >> >> >> >> see how<br>
>> >> >>>>> >> >> >> >> >> it<br>
>> >> >>>>> >> >> >> >> >> goes. It's just black box for me because unlike<br>
>> >> >>>>> >> >> >> >> >> option 2,<br>
>> >> >>>>> >> >> >> >> >> I<br>
>> >> >>>>> >> >> >> >> >> have<br>
>> >> >>>>> >> >> >> >> >> very<br>
>> >> >>>>> >> >> >> >> >> little control over what happens after building<br>
>> >> >>>>> >> >> >> >> >> the<br>
>> >> >>>>> >> >> >> >> >> shared<br>
>> >> >>>>> >> >> >> >> >> libraries,<br>
>> >> >>>>> >> >> >> >> >> and to make up for that I need to really get a<br>
>> >> >>>>> >> >> >> >> >> deep<br>
>> >> >>>>> >> >> >> >> >> understanding<br>
>> >> >>>>> >> >> >> >> >> of<br>
>> >> >>>>> >> >> >> >> >> how it works so I can make sure I code my CMake<br>
>> >> >>>>> >> >> >> >> >> scripts<br>
>> >> >>>>> >> >> >> >> >> properly<br>
>> >> >>>>> >> >> >> >> >> for<br>
>> >> >>>>> >> >> >> >> >> not only Android, but my other platforms as well<br>
>> >> >>>>> >> >> >> >> >> (non-Android<br>
>> >> >>>>> >> >> >> >> >> platforms).<br>
>> >> >>>>> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> Thanks again.<br>
>> >> >>>>> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher<br>
>> >> >>>>> >> >> >> >> >> <<a href="mailto:jomofisher@gmail.com">jomofisher@gmail.com</a>><br>
>> >> >>>>> >> >> >> >> >> wrote:<br>
>> >> >>>>> >> >> >> >> >> > Either option can work fine. Disclosure: I work<br>
>> >> >>>>> >> >> >> >> >> > on<br>
>> >> >>>>> >> >> >> >> >> > Android<br>
>> >> >>>>> >> >> >> >> >> > Studio<br>
>> >> >>>>> >> >> >> >> >> > and<br>
>> >> >>>>> >> >> >> >> >> > was<br>
>> >> >>>>> >> >> >> >> >> > the one that added CMake support.<br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> > Option (1) is the way it's designed to work and<br>
>> >> >>>>> >> >> >> >> >> > we're<br>
>> >> >>>>> >> >> >> >> >> > working<br>
>> >> >>>>> >> >> >> >> >> > toward<br>
>> >> >>>>> >> >> >> >> >> > getting<br>
>> >> >>>>> >> >> >> >> >> > rid of the need for the CMake fork. I can't<br>
>> >> >>>>> >> >> >> >> >> > really<br>
>> >> >>>>> >> >> >> >> >> > say<br>
>> >> >>>>> >> >> >> >> >> > when<br>
>> >> >>>>> >> >> >> >> >> > that<br>
>> >> >>>>> >> >> >> >> >> > will<br>
>> >> >>>>> >> >> >> >> >> > happen<br>
>> >> >>>>> >> >> >> >> >> > but if you can get away with an older CMake for<br>
>> >> >>>>> >> >> >> >> >> > now<br>
>> >> >>>>> >> >> >> >> >> > then I'd<br>
>> >> >>>>> >> >> >> >> >> > go<br>
>> >> >>>>> >> >> >> >> >> > this<br>
>> >> >>>>> >> >> >> >> >> > way.<br>
>> >> >>>>> >> >> >> >> >> > As you mentioned, option (1) will allow you to<br>
>> >> >>>>> >> >> >> >> >> > view<br>
>> >> >>>>> >> >> >> >> >> > your<br>
>> >> >>>>> >> >> >> >> >> > source<br>
>> >> >>>>> >> >> >> >> >> > file<br>
>> >> >>>>> >> >> >> >> >> > structure in Android Studio, edit files, and<br>
>> >> >>>>> >> >> >> >> >> > debug<br>
>> >> >>>>> >> >> >> >> >> > using the<br>
>> >> >>>>> >> >> >> >> >> > built-in<br>
>> >> >>>>> >> >> >> >> >> > debugging support.<br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> > To get option (2) to work, you can use jniDirs<br>
>> >> >>>>> >> >> >> >> >> > setting<br>
>> >> >>>>> >> >> >> >> >> > to<br>
>> >> >>>>> >> >> >> >> >> > tell<br>
>> >> >>>>> >> >> >> >> >> > Android<br>
>> >> >>>>> >> >> >> >> >> > Gradle where to pick up your built .so files<br>
>> >> >>>>> >> >> >> >> >> > (see<br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> > <a href="https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7" rel="noreferrer" target="_blank">https://stackoverflow.com/<wbr>questions/21255125/how-can-i-<wbr>add-so-files-to-an-android-<wbr>library-project-using-gradle-<wbr>0-7</a>).<br>
>> >> >>>>> >> >> >> >> >> > I'm not aware of any projects that use this<br>
>> >> >>>>> >> >> >> >> >> > approach<br>
>> >> >>>>> >> >> >> >> >> > but it<br>
>> >> >>>>> >> >> >> >> >> > should<br>
>> >> >>>>> >> >> >> >> >> > work<br>
>> >> >>>>> >> >> >> >> >> > in<br>
>> >> >>>>> >> >> >> >> >> > principal.<br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> > I hope this helps,<br>
>> >> >>>>> >> >> >> >> >> > Jomo<br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey<br>
>> >> >>>>> >> >> >> >> >> > <<a href="mailto:rcdailey.lists@gmail.com">rcdailey.lists@gmail.com</a>><br>
>> >> >>>>> >> >> >> >> >> > wrote:<br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> Right now I have custom targets set to execute<br>
>> >> >>>>> >> >> >> >> >> >> the<br>
>> >> >>>>> >> >> >> >> >> >> "ant<br>
>> >> >>>>> >> >> >> >> >> >> release"<br>
>> >> >>>>> >> >> >> >> >> >> command after my native targets are built. Part<br>
>> >> >>>>> >> >> >> >> >> >> of<br>
>> >> >>>>> >> >> >> >> >> >> that<br>
>> >> >>>>> >> >> >> >> >> >> command<br>
>> >> >>>>> >> >> >> >> >> >> involves copying *.so files to the<br>
>> >> >>>>> >> >> >> >> >> >> libs/armeabi-v7a<br>
>> >> >>>>> >> >> >> >> >> >> directory<br>
>> >> >>>>> >> >> >> >> >> >> so<br>
>> >> >>>>> >> >> >> >> >> >> they<br>
>> >> >>>>> >> >> >> >> >> >> get packaged in an APK.<br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> When switching to gradle, I have two options:<br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> 1. Gradle drives CMake: This means using<br>
>> >> >>>>> >> >> >> >> >> >> Android<br>
>> >> >>>>> >> >> >> >> >> >> Studio and<br>
>> >> >>>>> >> >> >> >> >> >> being<br>
>> >> >>>>> >> >> >> >> >> >> locked down to Google's fork of CMake which is<br>
>> >> >>>>> >> >> >> >> >> >> a<br>
>> >> >>>>> >> >> >> >> >> >> few<br>
>> >> >>>>> >> >> >> >> >> >> major<br>
>> >> >>>>> >> >> >> >> >> >> releases<br>
>> >> >>>>> >> >> >> >> >> >> behind. I see that as a negative.<br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same<br>
>> >> >>>>> >> >> >> >> >> >> or<br>
>> >> >>>>> >> >> >> >> >> >> similar<br>
>> >> >>>>> >> >> >> >> >> >> to<br>
>> >> >>>>> >> >> >> >> >> >> what<br>
>> >> >>>>> >> >> >> >> >> >> I'm<br>
>> >> >>>>> >> >> >> >> >> >> already doing: The custom targets I have would<br>
>> >> >>>>> >> >> >> >> >> >> execute<br>
>> >> >>>>> >> >> >> >> >> >> gradle<br>
>> >> >>>>> >> >> >> >> >> >> as<br>
>> >> >>>>> >> >> >> >> >> >> a<br>
>> >> >>>>> >> >> >> >> >> >> separate build step, instead of running ant<br>
>> >> >>>>> >> >> >> >> >> >> commands.<br>
>> >> >>>>> >> >> >> >> >> >> I'm<br>
>> >> >>>>> >> >> >> >> >> >> not<br>
>> >> >>>>> >> >> >> >> >> >> too<br>
>> >> >>>>> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you<br>
>> >> >>>>> >> >> >> >> >> >> tell<br>
>> >> >>>>> >> >> >> >> >> >> it<br>
>> >> >>>>> >> >> >> >> >> >> where<br>
>> >> >>>>> >> >> >> >> >> >> your<br>
>> >> >>>>> >> >> >> >> >> >> shared libraries are for the APK packaging<br>
>> >> >>>>> >> >> >> >> >> >> steps.<br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> Which does everyone recommend? Is anyone using<br>
>> >> >>>>> >> >> >> >> >> >> one<br>
>> >> >>>>> >> >> >> >> >> >> of<br>
>> >> >>>>> >> >> >> >> >> >> these<br>
>> >> >>>>> >> >> >> >> >> >> setups<br>
>> >> >>>>> >> >> >> >> >> >> successfully? The downside to option 2 is<br>
>> >> >>>>> >> >> >> >> >> >> probably<br>
>> >> >>>>> >> >> >> >> >> >> no<br>
>> >> >>>>> >> >> >> >> >> >> on-device<br>
>> >> >>>>> >> >> >> >> >> >> native<br>
>> >> >>>>> >> >> >> >> >> >> debugging since Android Studio probably can't<br>
>> >> >>>>> >> >> >> >> >> >> handle<br>
>> >> >>>>> >> >> >> >> >> >> gradle<br>
>> >> >>>>> >> >> >> >> >> >> projects<br>
>> >> >>>>> >> >> >> >> >> >> without any external CMake builds set up.<br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> Would like some general direction & advice<br>
>> >> >>>>> >> >> >> >> >> >> before<br>
>> >> >>>>> >> >> >> >> >> >> I<br>
>> >> >>>>> >> >> >> >> >> >> move<br>
>> >> >>>>> >> >> >> >> >> >> away<br>
>> >> >>>>> >> >> >> >> >> >> from<br>
>> >> >>>>> >> >> >> >> >> >> ANT. Thanks in advance.<br>
>> >> >>>>> >> >> >> >> >> >> --<br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> Please keep messages on-topic and check the<br>
>> >> >>>>> >> >> >> >> >> >> CMake<br>
>> >> >>>>> >> >> >> >> >> >> FAQ<br>
>> >> >>>>> >> >> >> >> >> >> at:<br>
>> >> >>>>> >> >> >> >> >> >> <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/<wbr>CMake_FAQ</a><br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> Kitware offers various services to support the<br>
>> >> >>>>> >> >> >> >> >> >> CMake<br>
>> >> >>>>> >> >> >> >> >> >> community.<br>
>> >> >>>>> >> >> >> >> >> >> For<br>
>> >> >>>>> >> >> >> >> >> >> more<br>
>> >> >>>>> >> >> >> >> >> >> information on each offering, please visit:<br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> CMake Support:<br>
>> >> >>>>> >> >> >> >> >> >> <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>support.html</a><br>
>> >> >>>>> >> >> >> >> >> >> CMake Consulting:<br>
>> >> >>>>> >> >> >> >> >> >> <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>consulting.html</a><br>
>> >> >>>>> >> >> >> >> >> >> CMake Training Courses:<br>
>> >> >>>>> >> >> >> >> >> >> <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>training.html</a><br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> Visit other Kitware open-source projects at<br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/<wbr>opensource/opensource.html</a><br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe:<br>
>> >> >>>>> >> >> >> >> >> >><br>
>> >> >>>>> >> >> >> >> >> >> <a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/cmake</a><br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> ><br>
>> >> >>>>> >> >> >> >> ><br>
>> >> >>>>> >> >> >> ><br>
>> >> >>>>> >> >> >> ><br>
>> >> >>>>> >> >> ><br>
>> >> >>>>> >> >> ><br>
>> >> >>>>> >> ><br>
>> >> >>>>> >> ><br>
>> >> >>>>> ><br>
>> >> >>>>> ><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>><br>
>> >> >><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>