[CMake] iOS multi-arch library target and xcodebuild

[Eric Wing]

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