Consider merging with https://github.com/willir/cargo-ndk-android-gradle

[ncalexan]

There's a second similar Rust + Android + Gradle plugin in this space, https://github.com/willir/cargo-ndk-android-gradle. Both lead developer @willir and I feel that we might profitably merge these two projects: see the little bit of discussion in https://github.com/mozilla/rust-android-gradle/issues/22#issuecomment-688345583, which I'm migrating here.

[ncalexan]

Here's the situation from where I stand. I'll speak from two perspectives: Mozilla's and my own, as an individual contributor to the plugin.

First, the plugin is actively used by Mozilla in https://github.com/mozilla/application-services and https://github.com/mozilla/glean, and both of those projects are large and active, so it's not going to die from lack of (institutional) use. However, the two people most associated with this project are not actively working in the area: that's me (I'm on a very different team these days) and Thom Chiovilini. At this point, Mozilla's needs are essentially met and the organization will mostly be keeping the lights on, ensuring that our builds don't break as Android and Gradle migrate forward, etc.

Second, I (personally) like the approach of invoking cargo ndk from the Gradle-layer more than I like the command line and environment variable munging that this plugin does. However, I note that https://github.com/bbqsrc/cargo-ndk doesn't seem particularly large or active, so the extra link in the dependency chain might not serve Mozilla's interests well. And some of the munging this plugin does is truly needed for Mozilla's use cases -- in particular, the linker wrapper scripts work around real bugs/issues that impact us significantly, although that may no longer be true. And Mozilla's cross compilation story is pretty complicated, although I don't think Rust feels that pain as much as some of our other C dependencies.

Third, I (personally) worry that the recognition of Mozilla's name will "crowd out" what might be the better project in this space, and would like to ensure that everybody gets a chance to play in the sandbox. Concretely, that might mean cross-linking between the two projects. I see that @willir has already done so, neatly comparing and contrasting the two projects up front. If it's not a good idea to merge efforts then we will reciprocate and guide users to an appropriate solution. We might also try to align our Gradle-level DSLs so that it's as easy as possible to move back and forth between the plugins.

So, what might we do? We might:

• Merge the projects. I (personally) don't think we'd ever want to merge away from cargo ndk, so we'd need to be confident that the things that Mozilla needs are supported in cargo ndk. And we'd need to have some confidence that the cargo ndk community is open to any changes. We'd need to arrange for folks from Mozilla to be able to publish the plugin so that in extreme circumstances Mozilla can make required fixes that block critical releases (since this is in the chain that publishes Firefox for Android). We might need to arrange more CI and testing for the plugin itself (this is something this plugin doesn't have, really, at all).

• Start a new shared project, deprecating both. I (personally) don't see why we'd do this, since the cargo ndk approach seems architecturally superior.

• Deprecate one or the other project. This is my (personal) preference. Mozilla doesn't have energy to really improve this plugin, but we also don't have motivation to switch to a new plugin. Issues here will languish, since there's no real owner at this time. (Well, it's me, but I have no time for this outside of my own interest and emergencies.) If we could duplicate useful things from this plugin over to https://github.com/willir/cargo-ndk-android-gradle, support an engaged owner for that plugin, and direct existing and new users to that plugin, that would be a great outcome. Mozilla can continue to use this implementation and the broader community can have a better experience elsewhere. Eventually, Mozilla can evaluate whether it wants to switch to the cargo ndk plugin and abandon this codebase completely.

Whew! What a long comment. @willir, what do you think? Others?

[ncalexan]

@rfk you're the most representative-y person from https://github.com/mozilla/application-services. Can you think a little about what a-s would like to see happen with this plugin? Happy to provide more context or hop on a video call if that would help.

[ncalexan]

@thomcc I've been assuming that you're not interested in maintaining ownership or involvement in this plugin, but I should verify that. What's you're preference?

[thomcc]

Nope, do what you want with it. Merging with the other tool makes sense to me from a not-duplicating-work perspective, though!

[rfk]

Thanks @ncalexan; my initial reaction aligns with your stated preference above, especially "Mozilla doesn't have energy to really improve this plugin". I think it makes sense to do what we can to support an move actively engaged maintainer and project in this space, even if we can't migrate our own usage with any particular urgency.

I'll keep this in my inbox to think more about it though.

[willir]

Hi @ncalexan, as far as I can tell, you would propose to merge some stuff from that project to mine, and become one of its owners? Please correct me if I'm wrong.

I don't mind that, or creating a new shared project based on cargo ndk.

We might want to see what features this project has that https://github.com/willir/cargo-ndk-android-gradle doesn't have. And which of those features aren't possible with cargo ndk.

Also, willir/cargo-ndk-android-gradle project is written in Groovy, and this one is in Kotlin. I don't mind rewriting mine in Kotlin if it can help merging process.

You were talking about tests too. Do you have any proposals of what would be the best way to test?

[gmale]

I work at ECC and we use a fork of the mozilla plugin in our official Zcash Android SDK, which powers a variety of Zcash apps. We have contributed some of our changes up-stream (for using the pre-built toolchains in r19+) but we have a few other changes like selecting rust features for specific android variants that remain in our fork.

Given @ncalexan's comments, I'd be willing to try switching to cargo-ndk-android-gradle in our project and, if it works for us, then actively contributing as Android evolves.

We just had an issue yesterday where a contributor who was using Windows couldn't build and it turned out to be an issue with his python installation. I came here to see if it was worth trying to submit a patch (perhaps to at least give a more descriptive error when linker-wrapper.bat fails to find python) but, after reading this thread, it seems that it might be better to direct that energy toward cargo-ndk-android-gradle.

I'll try the plugin out in our project later this week.

[ncalexan]

I work at ECC and we use a fork of the mozilla plugin in our official Zcash Android SDK, which powers a variety of Zcash apps. We have contributed some of our changes up-stream (for using the pre-built toolchains in r19+) but we have a few other changes like selecting rust features for specific android variants that remain in our fork.

Given @ncalexan's comments, I'd be willing to try switching to cargo-ndk-android-gradle in our project and, if it works for us, then actively contributing as Android evolves.

We just had an issue yesterday where a contributor who was using Windows couldn't build and it turned out to be an issue with his python installation. I came here to see if it was worth trying to submit a patch (perhaps to at least give a more descriptive error when linker-wrapper.bat fails to find python) but, after reading this thread, it seems that it might be better to direct that energy toward cargo-ndk-android-gradle.

I'll try the plugin out in our project later this week.

Hi @gmale! Pleased to hear y'all are getting value out of this plugin. If cargo-ndk-android-gradle will work for you, I do think that is likely to be the best option, since that plugin's community can more actively direct resources than can this plugin's community, which will always be pulled in Mozilla's direction.

Should cargo-ndk-android-gradle not be appropriate -- and if so, please let us know what's truly different -- then let me float an alternative: one of your group could become a joint maintainer of rust-android-gradle. I'm certainly open to motivated folks helping pull the oars, as it were.

[willir]

Hi @gmale, I should add that I would be glad if cargo-ndk-android-gradle works for you. If you have any issues, I hope we can fix them asap.