On 1/10/14, Stephen Kelly <steve...@gmail.com> wrote: > Vince Harron wrote: > >> Android.mk files allow you to target multiple processor >> architectures/variants in one make invocation without any reconfiguring >> or >> multiple build folders. All of those binaries are embedded into one >> "fat" >> apk file that will run on any supported Android device. > > Sounds interesting. > >>> Modules/Platform/Android.cmake >> >> I've just started playing with it like this as my Android.cmake >> >> include(Platform/Linux) >> >> But it's critical to have Android as a separate CMAKE_SYSTEM_NAME because >> there are many differences that you might want to switch on. > > Indeed. Disabling SONAME is another apparently: > > http://public.kitware.com/Bug/view.php?id=14602 > >>> Why does that link also say that Android.mk files are only for creating >> shared and static libraries? Am I missing something here? >> >> All Android applications start life as Java processes. A java process >> can >> load a native shared library and invoke code within it. To emit a C/C++ >> executable on Android is the same as to emit a shared library, but linked >> to something called the native_app_glue module. > > Interesting. What is the entry point? > > > I don't decide whether such a generator gets in or not, but I don't see why > > it would not be accepted. > > Thanks, > > Steve. >
I agree that we should have a “native” Android NDK build generator. There are some things that are harder to do outside the native build process (some which have already been identified in this thread) - Multiple architecture support (armeabi, armeabi-v7a, x86, mips). Though these aren’t “fat” binaries in the NeXT/Apple model. They merely introduce an extra subdirectory layer of indirection and place each binary in the properly named folder. However, since the Android model knows how to handle this, it would be very nice to have (because my current workaround is to invoke CMake for each architecture and then glue everything with my own post build scripts written in bash or Perl…yuck). - I’m not sure if this is the SONAME example mentioned, but Android can’t handle the .so version numbering scheme where version numbers are put in the file name and symlinks are used to point a version-less file to a specific version. The NDK design is to use Java’s System.loadLibrary to load NDK modules, and it turns out that loadLibrary can’t handle symlinks. - gdb debugging does some voodoo that is technically open, but not really well documented or fully understood. I’ve some people try to recreate it and document it for external tools like CMake, but it’s work. The native system generally sets this up for you. (Though I have a lot of problems getting regular Android stuff to ‘just work’.) However, as a counterpoint, I will say that the NDK is a broken/incomplete piece of $%#!, and in most respects, CMake’s generic makefile system is vastly better. So I would actually like to see CMake’s generic generator extended for Android. - For example, did you know that compiling for size (-Os) is not supported by the NDK? This is the stupid platform that limits you to 50MB .apk’s. What the $%$ are they thinking? I have the misfortune of porting JavaScriptCore to Android and just getting it to build (and verify it), the time involved has been measured in weeks spanning months. Currently I’m trying to shrink the binaries because JSCore is huge. Currently, the smallest I can get each architecture is about 30MB each. I’m building with CMake, so I can at least get access to the -Os flags and actually control many build flags the NDK won’t let me access. I would be totally screwed without this. - Android introduced -mhard-float for processors that support it. However, one serious problem is that you can’t use that on any code that touches/crosses the Java JNI layer (because I think the Java VM doesn’t expect arguments to be in float registers). Since Android forces you to always go through Java, you always have to cross the JNI layer somewhere. So, the obvious workaround is to specify CFLAGS per file. But this is not possible with the native NDK build system. (I haven’t checked r9c yet, which just came out.) - Google hasn’t answered the question about how the NDK is going to work with their switch to Gradle and IntelliJ. Honestly, Google has a terrible track record with the NDK and I trust CMake a lot more than I trust Google. (There's another story about Gyp lurking in here in prior attempts to build JSCore before my involvement.) This all said, I’ve forked the Android-CMake cross-compiler chain (originally developed by the OpenCV people I believe) to keep it going for the latest NDKs. I haven’t had much success with the direct toolchain, but I have been very successful with the standalone toolchain. I would like to rally more support to improve this toolchain as well and maybe even get it included in some form in the official CMake distribution. While it works, there are still lots of pain points like multiple architectures which I already mentioned I string together with Perl scripts. That fork an be found here: https://bitbucket.org/ewing/android-cmake I have a good real world case of how all this works. It is good because it is non-trivial and reflects real world usage, but also not so complicated (unlike JSCore) where you’ll never figure it out. https://bitbucket.org/ewing/hello-android-almixer This hello world is standard Android app that is written in Java with JNI APIs that can call into C. The program uses ALmixer (my OpenAL based audio library). ALmixer uses CMake to build. ALmixer has dependencies on both Android’s OpenSL ES (provided in the NDK) and also an Android fork of OpenAL-Soft. What is interesting about OpenAL-Soft is that it has yet its own build system, so this example shows how to string 4 different build systems together. (OpenAL-Soft, ALmixer via Android CMake, the app’s ndk standard build system, and the standard (though now deprecated because of the Gradle planned switch) ant build system for the Java stuff. Part of the glue is using the standard Android NDK external module system in this process. Anyway, I would like to see CMake support both ways so we developers can “pick our poison” when dealing with Android. And I welcome any help improving Android CMake. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
