Comment by flohofwoe
6 months ago
The Android NDK just barely supports C and C++ either, unless you're ok with 1990's tooling standards. The whole thing feels like it's maintained by two dudes locked in a Google basement somewhere. I doubt they have the capacity to deal with Rust support in the NDK, unless there's a big strategic change in Android tooling.
I'm not sure what you mean by this. Looking at a sample app [1] for the NDK, the tooling appears to be gradle and Cmake. Cmake isn't the newest of tools, but it's also not that dated.
[1] https://github.com/android/ndk-samples/tree/main/endless-tun...
Both Gradle and CMake have a strong late 1990's smell to them. While CMake is sort of a necessary evil in the C/C++ world, there's no excuse for dragging Gradle into the NDK, combining both build tools leads to a complexity explosion that rarely works and tends to break after either the NDK or SDK is updated, or somebody merely looks the wrong way at the build files.
CMake is the defacto tool adopted by the industry, regardless how many love to hate it.
You can use BSD Make instead of Gradle, isn't UNIX great?
2 replies →
Nope it clearly supports ISO C 11 and ISO C++17.
I do agree the NDK team is rather small.
Huh? "Barely"? What are you talking about? The NDK supports compiling C++ just fine. There are CMake files, among other things, ready to use --- as well as Soong native configurations. CMake is under active development. Other toolkits are within easy reach: for example, Meson works fine. Also Bazel. Hell, even autotools can be made to work.
Sure, building C/C++ code into an .so file kinda works but that's about it, try building the APK entirely with cmake, that's simply not supported, you'll have to integrate with Gradle. The result is a complexity clusterf*ck that's a nightmare to maintain.
The NDK team should take a long hard look at Emscripten to get some inspiration how native code development is integrated into a 'native-hostile' runtime platform.
I've never understood why developers fixate on having "pure" NDK-based apps. It's really not that hard to implement Activity, Service, etc. as JVM in Kotlin or Java and call the native code via JNI. What do you think the "pure native" app layer in Android is doing if not that?
1 reply →
Interesting that you give Emacripten as example, given how badly documented its whole tooling is, and is a pain to prevent it from downloading the Java tooling and everything else that is already downloaded, unless using the Github installation from source.
2 replies →