Comment by quotemstr
6 months ago
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?
It's not about the idea of writing a pure native app, but about making it easier to build a hybrid app without an exploding build process complexity.
Emscripten is again a perfect example of how it should be done: FFI calls into Javascript are trivial (it's even possible to embed JS code into C/C++ source files), and I can build a complete hybrid WASM/JS app without having to bring in a completely different build system that's completely alien to the C/C++ world.
It even works without any build system at all since the emcc compiler/linker wrapper is also the Javascript bundler, yet the entire emcc wrapper acts like a GCC/Clang compatible compiler/linker with some extra Emscripten specific flags. The Emscripten SDK didn't jump into existance like this, the difference to the NDK team is that the Emscripten team actually listens to their users.
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.
The one great feature of Emscripten is that you can do:
...and it produces an output that's immediately runnable in a web browser instead of just a bare .wasm file which needs to be wrapped in a html with additional steps.
E.g. emcc is a drop-in replacement for gcc/clang which can be used directly in a C/C++ build tool as a C/C++ compiler and linker while still doing the right thing (producing a runnable .html).
The NDK equivalent would be a gcc-compatible compiler wrapper which can do this:
...such a simple and obvious thing to do, yet it doesn't happen because the Android SDK/NDK developers have no clue about developer workflows outside of their precious Java ivory tower.
> and is a pain to prevent it from downloading the Java tooling and everything else that is already downloaded,
That's a feature, not a bug. It's trivial to install different emsdk versions side by side, each entirely self-contained and without polluting the system or requiring external dependencies.
The separate Java dependency also has been dropped a while ago, since the only remaining component that depends on Java is the optional Closure compiler step, and that comes now with an embedded Java runtime (as far as I'm aware at least).
1 reply →