[cmake-developers] Fw: Please comment on ios-universal topic

Bartosz Kosiorek Bartosz.Kosiorek at tomtom.com
Thu Dec 3 06:45:09 EST 2015


Hello Ruslan

The Android supports both Universal Apk and Multi Apk.
 https://androidbycode.wordpress.com/2015/07/07/android-ndk-a-guide-to-deploying-apps-with-native-libraries/ 
 http://developer.android.com/google/play/publishing/multiple-apks.html

It is necessary for deploy applications which support both armv7 (32bit) and armv8 (64bit).
There is also Intel's implementation of Android (x86)
All supported architectures you could found at:
   http://developer.android.com/ndk/guides/abis.html

It is possible to create universal library for Linux (FatElf), but it is not widely used:
http://stackoverflow.com/questions/10167821/why-are-universal-binaries-fatelf-not-part-of-linux-kernel

I don't know how it works with Universal Windows Platform:
https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx
https://msdn.microsoft.com/en-us/library/mt186162.aspx
But I suspect that it will be similar.

Best Regards
Bartosz

________________________________________
From: Ruslan Baratov <ruslan_baratov at yahoo.com>
Sent: Thursday, December 3, 2015 11:06 AM
To: Bartosz Kosiorek
Cc: Gregor Jasny; cmake-developers at cmake.org
Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic

On 03-Dec-15 14:57, Bartosz Kosiorek wrote:
> Thanks Ruslan for feedback.
>
> I think that this new property should work also for FRAMEWORK and should support both OSX and iOS
> In that way it is already done for:
>   -  for SHARED library adding FRAMEWORK property produce correct Framework for iOS or OSX (for Cmake 3.5 the documentation was already updated), and standard library for other platforms
>   - for MACOSX_BUNDLE (the name of property is very confusing). It will produce BUNDLE for OSX or iOS.
>   - even standard SHARED library produce different results according to platform (.so file on Linux, .dll on Windows, .dylib on OSX)
>
> I strongly believe that this new CMake's property should follow this convention.
>
> Currently I'm working in project which must support multiple platforms (Linux, Windows, OSX, iOS, Android, QNX etc.).
> And I very like CMake for automagicaly adopting to platform/architecture/OS.
>
> Because "Universal Library" is generic name, which is applicable for all platforms (Fat library is used on Apple machines),
> I would like to propose following  property name:
>      INSTALL_UNIVERSAL_LIBRARY
>
> For now it will be applicable only on iOS (OS X?), but it could be extended to other platforms (Android).
> Of course all supported platforms should be noticed in documentation.
>
> What do you think about that idea:
> Adding one property which will adopt to platform on which is build?
Actually it make sense to me. We just need to add a note to the
documentation that only Xcode + iOS libs supported for now and add new
types/platforms in future.

By the way does any other platform except Apple's OSX and iOS support
fat libraries? You've mentioned Android (?) I've found this link about
Linux:
https://en.wikipedia.org/wiki/Fat_binary#FatELF:_Universal_Binaries_for_Linux
(quote: `developer Ryan Gordon declared FatELF to be dead`)

Ruslo

>
>
> Best Regards
> Bartosz
>
> ________________________________________
> From: Ruslan Baratov <ruslan_baratov at yahoo.com>
> Sent: Thursday, December 3, 2015 4:09 AM
> To: Bartosz Kosiorek
> Cc: Gregor Jasny; cmake-developers at cmake.org
> Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic
>
> On 02-Dec-15 19:44, Bartosz Kosiorek wrote:
>> Hi.
>>
>> Currently we already support similar target properties:
>> - INSTALL_NAME_DIR
>> - INSTALL_RPATH
>> - INSTALL_RPATH_USE_LINK_PATH
>>
>> It will be great to follow the same name convention.
>>
>> Because this new property is only applicable for INSTALL step, I would like to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS.
>>
>> What do you think about that idea?
> It's hard for me to decide what is better because
> IOS_INSTALL_UNIVERSAL_LIBS just came from my mind and I've used it for a
> while already. So now it looks solid for no reason :)
>
> However first note:
>     INSTALL_RPATH can be read as when we do INSTALL change RPATH to ...
> (any platform)
>     ANDROID_API -//- when we are on ANDROID use next API ...
>     WIN32_EXECUTABLE -//- when we are on WIN32 use bla-bla for EXECUTABLE
>     OSX_ARCHITECTURES -//- when we are on OSX use ARCHITECTURES
>     MACOSX_BUNDLE -//- when we are on MACOSX create BUNDLE
>
> So new property can be read as:
>     IOS_INSTALL_UNIVERSAL_LIBS when we are on IOS do INSTALL_UNIVERSAL_LIBS
>     INSTALL_IOS_UNIVERSAL_LIBS when we do INSTALL make IOS_UNIVERSAL_LIBS
> (does it mean that when we are on Linux we can install iOS libs? does it
> mean that when we are on OSX without iOS toolchain we can do iOS libs?)
>
> Second note is about future improvements of this feature, installing
> universal libs on OSX or installing universal frameworks, pattern
> <platform>_INSTALL_UNIVERSAL_<type>:
>
>      IOS_INSTALL_UNIVERSAL_LIBS
>      IOS_INSTALL_UNIVERSAL_FRAMEWORKS
>
>     OSX_INSTALL_UNIVERSAL_LIBS
>     OSX_INSTALL_UNIVERSAL_FRAMEWORKS
>
>     INSTALL_UNIVERSAL_LIBS # on both OSX and iOS
>     INSTALL_UNIVERSAL_FRAMEWORKS # on both OSX and iOS
>
>     IOS_INSTALL_UNIVERSAL # both libs and frameworks
>     OSX_INSTALL_UNIVERSAL # both libs and frameworks
>
>     INSTALL_UNIVERSAL # both libs and frameworks, both OSX and iOS
>
> ?
>
> Ruslo
>> ________________________________________
>> From: cmake-developers <cmake-developers-bounces at cmake.org> on behalf of Gregor Jasny via cmake-developers <cmake-developers at cmake.org>
>> Sent: Tuesday, December 1, 2015 3:22 PM
>> To: CMake Developers; Ruslan Baratov
>> Subject: [cmake-developers] Please comment on ios-universal topic
>>
>> Hello,
>>
>> During the last days I worked on the iOS Universal Install topic which
>> now would benefit from a review. Especially the core changes could need
>> a third pair of eyes:
>>
>> https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=8fb23b42cfc2fb7490e8645fff328add9c231713
>>
>> I will now concentrate on adding more tests during the next days.
>>
>> Thank you,
>> Gregor
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers


More information about the cmake-developers mailing list