[cmake-developers] [Generator] Android.mk

[Stephen Kelly]

Eric Wing wrote:

> On 1/10/14, Stephen Kelly
> <steveire at 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.