Eric Wing wrote: > 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 not directly related, it would be good to have http://public.kitware.com/Bug/view.php?id=14539 in mind when implementing this generator for future consideration and so that the features don't conflict with each other. > - 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. Yes, this is the issue I meant, but I didn't know the detail or reasons behind it, thanks. Thanks, Steve. -- 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
