search

mozilla / mentat

UNMAINTAINED A persistent, relational store inspired by Datomic and DataScript.
https://mozilla.github.io/mentat/
Apache License 2.0
1.65k stars 115 forks source link

Build android sdk #795

Closed ncalexan closed 6 years ago

ncalexan commented 6 years ago

It's not at all obvious, but this (and some manual release tagging, which I've since rolled back) triggered this "release" task which uploaded a Mentat 0.8.1 AAR to https://bintray.com/pocmo/Mozilla-Mobile/mentat. That's a lot of #794. The last mile is to get from @pocmo's private bintray account to jcenter or some other Mozilla-run Maven repository, but we can work on that in the coming days. Progress!

@fluffyemily, this is relevant to your work on running Android tests in automation. If you wanted to, you could stick additional testing tasks into https://github.com/mozilla/mentat/pull/795/commits/d073ed9fdb88cd28c5e602924bdf2e7cb7287b42#diff-829bf5d0c2cb4f06d8e29f35febd5707R116, although maybe it's better to use Travis's excellent support for Android x86 emulators.

ncalexan commented 6 years ago

This isn't quite ready for review. I'd like to push the Gradle plugin I'm using to build the Rust code somewhere outside of Mentat, and get a little more opinion on it from other folks in our Android components group; and I must bump the set of supported built architectures.

ncalexan commented 6 years ago

@csadilek, @vladikoff -- could you folks take a look at this PR, in particular the very simple Gradle plugin that I cloned from https://github.com/nishtahir/rust-android-gradle in https://github.com/mozilla/mentat/pull/795/commits/6898bac83db95c37bb19c2d8b129dc4a5f4a6bb8, and see if you're okay with this approach?

It's basically just invoking cargo, with a tiny bit of toolchain management around the edges; but it does make working on an Android wrapper for a Rust library that little bit more pleasant.

Thanks!

csadilek commented 6 years ago

@ncalexan looks good to me. Not very familiar with the rust/crate world though. One thing I am wondering about is the location of the jni libs. In our current library, we're putting them into src/main/jniLibs which has the advantage of not requiring any build configuration for the app. Of course, we could still take care of that in the component?

ncalexan commented 6 years ago

@ncalexan looks good to me.

Thanks for looking promptly.

Not very familiar with the rust/crate world though.

Understood. I was really looking for a once over of the plugin code and general approach. I've written lots of Gradle-specific code, but not much plugin code; and not written any Kotlin!

One thing I am wondering about is the location of the jni libs. In our current library, we're putting them into src/main/jniLibs which has the advantage of not requiring any build configuration for the app. Of course, we could still take care of that in the component?

Internally, the plugin is pushing the Rust libraries into ${buildDir}/rustJniLibs and then adding that directory to the main.jniLibs source set. I did this to make it really clear while debugging which libraries are being produced by Cargo. Consumers of the resulting AAR don't have to do further configuration -- they're in the jniLibs directory as usual. (I tested this locally, pulling from my personal bintray Maven repo.)

csadilek commented 6 years ago

Internally, the plugin is pushing the Rust libraries into ${buildDir}/rustJniLibs and then adding that directory to the main.jniLibs source set.

Thanks, got it. That's perfect then!

vladikoff commented 6 years ago

It's basically just invoking cargo, with a tiny bit of toolchain management around the edges; but it does make working on an Android wrapper for a Rust library that little bit more pleasant.

👍