search

bbqsrc / cargo-ndk

Compile Rust projects against the Android NDK without hassle
Apache License 2.0
712 stars 64 forks source link

Specifying android ndk version without full path? #109

Closed fzyzcjy closed 1 year ago

fzyzcjy commented 1 year ago

Hi thanks for the tool! I see the current method of finding ndk is:

If you have installed the NDK with Android Studio to its default location, cargo ndk will automatically detect the most recent NDK version and use it. This can be overriden by specifying the path to the NDK root directory in the ANDROID_NDK_HOME environment variable.

However, I would appreciate it if I could lock the version of ndk (say, lock to 21.1.6352462), while do not provide the absolute path of ndk directory but let the cargo-ndk auto find it.

bbqsrc commented 1 year ago

I appreciate the desire for such a feature, but it's not a maintainability burden I'm willing to entertain at this time. Sorry!

fzyzcjy commented 1 year ago

It's OK! So is it possible to expose a method, say, cargo ndk get-current-ndk-path, which returns the ndk you automatically choose. Then I can use this data to create the path I want (the pinned ndk version). This will not introduce maintainbility IMHO, since it does nothing but simply exposing what is already implemented.

bbqsrc commented 1 year ago

All things are possible but I aim to keep cargo-ndk as close to "zero features" as possible. The tool only exists because the NDK is an aberration to the extent that doing anything for Android directly with cargo is a nightmare of environment variables and weird errors that are hard to diagnose. Ultimately, I hope for this tool to be completely redundant eventually.

I do not want the tool to include features that other tools become dependent on. cargo-ndk should only be used to the extent that it smoothes out the rough edges of building Rust crates for Android, with a particular amount of sympathy for those users trying to build crates with C dependencies. Anything that goes beyond what we would expect of a well-oiled NDK integration in cargo itself is out of scope.

The auto-detection only exists because Android Studio decided to introduce the multi-version nonsense which made doing anything even half-resembling CI a massive pain every time the base image was updated. I was reluctant to add it then, and I somewhat regret having added it now even though it is a great convenience.

I strongly recommend providing explicit environment variable paths to the specific NDK to be targeted if using the most recent version is not the desired behaviour. Being explicit to this extent is, to my mind, the best practice.

Environments differ so significantly between systems that any desire to automate this will just lead to more bug reports in the future (for me and/or the dependent projects), made all the more obscure by the layering of tools, differing operating systems, and constant random breakage from Google screwing around with how the NDK is structured (which happens basically every release).

fzyzcjy commented 1 year ago

@bbqsrc I see. Thank you for the reply!