[CMake] iOS multi-arch library target and xcodebuild

[Ruslan Baratov]

On 25-Jun-15 02:26, Eric Wing wrote:
> On 6/24/15, Ruslan Baratov via CMake <cmake at cmake.org> wrote:
>> On 24-Jun-15 23:03, Bill Hoffman wrote:
>>> What is in the patched CMake?
>> * workaround for bug: http://public.kitware.com/Bug/view.php?id=12506
>> * installing universal simulator + device library
>>> CMake already supports mulit-arch libraries on the Apple platform.
>> As far as I know you can build two libraries: one for simulator, like [
>> i386 + x86_64 ] and one ARM, like [ armv7 + armv7s + arm64 ]. Patched
>> CMake version run some extra CMake commands to link them together into [
>> armv7 + armv7s + arm64 + i386 + x86_64 ] fat library.
>>
>> On 25-Jun-15 00:00, headupinclouds wrote:
>>> I had thought that the iOS simulator x86_64 architecture was not
>>> supported in the same FAT library as the arm architectures without the
>>> patch, but I could be wrong.
>> Exactly
>> --
> Ooh. This sounds really interesting. Does this also mean that CMake
> doesn't need to use an external iOS toolchain anymore?
>
> So to clarify, these were some of the problems I have (had?) with CMake on iOS:
>
> - Almost all the problems stem from how the SDK root is defined in CMake.
>
> - iOS simulator and iOS device use different SDKs and Xcode is
> supposed to dynamically switch them depending on your current Xcode
> selection (either in the GUI or command line invocation).
>
> - iOS treats these as separate SDKs with completely different paths
> for both inputs (e.g. headers, dynamic libraries, etc), and outputs
> (build products)
>
> - iOS doesn't combine simulator and device binaries into fat binaries
> and instead opts for two completely different paths for everything.
> This has created extraordinary pain for 3rd party middleware
> developers or people wanting to use pre-built frameworks. Apple has
> done pretty much nothing to make this situation bearable.
>
> - As such, developers make their own fat binaries by manually
> combining the device and simulator binaries together with lipo.
>
> - Apple engineers have warned not to do that. However, their lack of
> providing any other reasonable solution after 7 years just makes them
> seem obstinate. (I suspect they want to keep room open for a mythical
> x86 iOS device, and refuse to solve our real problems of today.)
>
> - The new iOS framework feature throws another monkey wrench for the
> manual lipo workaround because in building the final app, the
> framework gets bundled as-is, with all the architectures in place.
> Without manual intervention, you will attempt to ship an iOS app to
> the store that contains simulator binaries and will likely be
> rejected. (There was a recent mailing list thread asking how to solve
> this...no good solution was found.)
>
>
>
> - Anyway, CMake has trouble with singular SDK root.
>
> - FIND_LIBRARY is problematic for system frameworks because the path
> needs to change depending on device or simulator. My workaround is to
> manually write "-framework Foo" instead of using FIND_LIBRARY for
> Apple system frameworks. (I can continue to use FIND_LIBRARY for 3rd
> party frameworks, but must make sure they are fat.)
>
> - I believe I had to tweak my toolchain to write values that matched
> Xcode more closely, otherwise switching between device and simulator
> wouldn't work.
>
> - Because Xcode/xcodebuild put products in different directories for
> device vs simulator, I end up manually running standalone shell
> scripts to find these products and lipo them.
>
> - I would like to be able to write shell scripts that get run as part
> of Xcode's built-in shell-script phase because certain useful Xcode
> environmental variables are set/available when you do that. But CMake
> doesn't have a mechanism to do this as far as I know, so I have to
> hard code things that are variable by Xcode and subject to change.
>
>
> Then there are other CMake problems not directly related to this, such
> as switching codesigning keys, invoking the Archive feature (kind of
> needed for deploying), setting entitlements, and still clumsy areas
> where the CMake generated Xcode UI is missing stuff from a normal
> Xcode project. (Setting things like entitlements, Game Center stuff,
> orientation settings, and just being able to quick add a framework for
> experimentation.) And many of these are problems for Mac too now.
>
> Thanks,
> Eric
tl;dr Everything works fine. This project 
https://github.com/ruslo/weather uploaded to AppStore without problems: 
https://itunes.apple.com/us/app/weather-with-hunter/id885350236

* iOS toolchains I'm using: https://github.com/ruslo/polly (used to 
switch between different SDKs + to add some flags, like -std=c++11)
* Hunter install 5-arch 3rd party fat libraries so I can run 
simulator/device in single Xcode instance
* when I run "Archive" for preparing my application for uploading to 
AppStore Xcode uses only device architectures. Just set "Build Active 
Architecture Only" to NO and universal application for device will be built
* I see no point of using frameworks for managing 3rd parties. Plain 
`<root>/include` and `<root>/lib` layout works for iOS (and for all 
others platforms like MSVC, MinGW, ...)
* toolchain used to switch between different SDK's. You just need to set 
environment variable IOS_X_Y_DEVELOPER_DIR. See 
https://github.com/ruslo/polly/wiki/Toolchain-list#ios
* Hunter automatically set CMAKE_PREFIX_PATH and <package>_ROOT to the 
root directory of 3rd party libraries so `find_package` works fine

Since you've touched too many aspects I may miss something. Let me know 
if I've not covered some important stuff.