search

willir / cargo-ndk-android-gradle

Cargo NDK for Android projects
Apache License 2.0
55 stars 7 forks source link

Consider building for desktop #12

Open Progdrasil opened 3 years ago

Progdrasil commented 3 years ago

I've hit a snag where I'm trying to run unit tests with Junit on my bindings to make sure everything works nicely. Unfortunately I keep hitting the following error: no core in java.library.path. After a lot of searching i think its the fact that the libraries built are for the android os using cargo-ndk and there's no way to build for the desktop like the mozilla plugin does. Unfortunately that plugin does not work for me either because of an issue in discovering cargo

willir commented 3 years ago

So cargo-ndk doesn't allow to build for desktop? Or cargo-ndk itself is fine, we just need to adopt this plugin?

Progdrasil commented 3 years ago

Cargo ndk only allows to compile using the Android NDK so only for *-linux-android* targets. The difficulty with this is if i need to run tests on my bindings, i can theoretically just run normal unit tests. However unit tests run on the hoat machine and not on emulators of android devices. I have to either

willir commented 3 years ago

And it probably doesn't make sense for cargo-ndk to compile for the host, because for the host you don't really need ndk :-)
Do you have any idea/suggestions on how to change this plugin (at least from a top-level usability perspective) to make it compile for desktop?

I assume that if you go to your rust project and manually build/run tests with cargo it works? However, if it would work through Android Studio out of the box it would be nicer?

Let me know if I miss anything.

Progdrasil commented 3 years ago

Top level it would be nice to simply have a "host" entry in the targets, or something similar so that this plugin just works in android studio.

One thing i did on my end was to change the cargo compilation when running a task of type Test to only compile for host since the cross compiled versions of he library are unused and slow down the test-code cycle.

Im guessing this optimisation can also be applied for instrumented tests as well, though im not sure what the type for those are.

ianthetechie commented 8 months ago

I regrettably don't have much to add as my knowledge of Gradle is like 3 orders of magnitude less than my knowledge of cargo, but I'd like to echo that his would be nice to have. Not just because it's more efficient, but also because, somewhat understandably, neither gradle build nor gradle test will invoke Android tests, so it really requires going out of your way to test that things are still working on Android.