[cmake-developers] iOS support

[Eric Wing]

On 9/23/14, Florent Castelli <florent.castelli at gmail.com> wrote:
> Hi!
>
> My company is organizing soon a hack week where each employee is able to
> work on any project he wants. So, I've decided to work with Cmake and
> improve support for iOS to help the product team getting rid of manual
> project files, constant merge conflicts and bad project file documentation,
> while improving our tooling possibilities (all that with Cmake!).
>
> I've had a quick look at the first issue that popped into my mind the other
> day and fixed try_compile by adding another variable to set the executable
> type in the generated project (it has to be MACOSX_BUNDLE) and fixing the
> search path for the resulting binary.
> So this is now working... Providing we are targeting the simulator.
> Due to the nature of Xcode projects that can easily target either the
> simulator or devices, thus using different compilation flags, the resulting
> projects aren't working in both case. There are conflicts between some
> options like the minimum iOS version target and the minimum iOS simulator
> target for example (which you need to build the try_compile binaries
> without signing them).
> Also, the Xcode support is very OSX focused and all variables have MACOSX
> in their name, which is confusing.
>
> So, has anyone worked on similar issues and can suggest a way to progress
> and improve support for iOS?
> In the end, I'd like to have a working Xcode project with separate settings
> for both simulator and device, Cmake compiler flag detection working, and
> possibly later Make/Ninja projects working too.
>
> Regards,
> /Orphis
>

This is off the top of my head, and its late...
Some context...I'm developing a new SDK for game developers. I've been
spending a lot of time with the generators (Windows, Linux, Mac, iOS,
Android, and playing with Windows Phone recently). CMake is the best
game in town for handling all these platforms. But there are also a
ton of things that annoy me. My goal is to help people build apps they
can ship, but much of CMake's thought process is about building apps
locally for your system and the work flow isn't correct in my opinion.
I've done a lot to address these short-comings and I hope to clear
some time to talk about all this and share my changes in the near
future. (Especially the Android stuff...I had to build a lot of crap
to make that work and I would like to fold that back into the CMake
core because it is evil.)

As for iOS (and some Mac), one of my peevs is that the application
bundle process doesn't happen as part of the build. For a normal
Mac/iOS development, you always rebuild your code and your application
bundle. CMake treats this as two discrete steps so what you
develop/test is different from what you ship. (And incidentally in the
Visual Studio case, I discovered it is impossible to launch your app
via the debugger because of this too.)

Additionally, the iOS/CMake stuff is flakey about letting you switch
between device and simulator. You shouldn't have to generate a
completely different project to test between the two. This is not how
iOS developers work nor how the Xcode toolchain is designed. (And now
that we have 32-bit and 64-bit versions of both, it's ridiculous.) I
some how got mine to the point where I can switch targets in the same
project, but it's flakey due to the way CMake injects paths/values
into the Xcode project. It isn't the same exact values as Apple, so
somethings like finding frameworks/libraries cause me to do some
tricks.

Also on that note, just getting CMake to pick the proper "Lastest SDK"
value by default would be nice. It is hard coding some full path which
seems to work in base cases, but causes me problems in other cases. I
noticed when Xcode versions change, this often is the main culprit for
new breakage.

All the configuration options are blank for me. The Mac one works, but
iOS is blank for me. This means thinks like all my optimization
settings are the same (debug and release have the same values).

I can set these values manually, but I have only been able to do it to
my own targets explicitly. My attempts to set the values globally (at
the root) have not succeeded.


I still haven't dealt with launch images and icons. A proper sized
launch image is required to get the iPhone 5 and iPhone 6 "tall"
resolutions without letterboxing. I'm not sure what the right thing to
do here is with CMake.


I'm doing my own application bundling to some degree. As I said,
CMake's normal process goes against the grain of the normal workflow
so I changed it to behave like the real thing. I'm having trouble
remembering, but I think the CMake/Mac had better handling than
CMake/iOS. CMake was doing some stuff for me better than iOS, but I
don't fully remember. (May have something to do with listing resources
as part of the target.) But one place I found CMake to be really
annoying was with nested directories and also symlinks. Copying a
framework into a bundle is a good example because it has both. And
ideally, you only want to do it when there is a change. (I think I got
lazy and call rsync in some places since I know it is installed on
Mac.)




Codesigning for both Mac and iOS I haven't figured out yet either. On
iOS, you have development and distribution keys. On Mac, you also have
Mac App Store vs. GateKeeper.


Xcode normally gives you a display to let you see and configure
important things like Sandboxing options, launch images, icon
resolutions, code signing. But when going through the CMake generator,
it doesn't show any of this stuff. I don't know why, but it's
disturbing/scary (because it feels broken/fragile) and annoying. Maybe
updating the underlying Xcode template CMake uses will help?

I would like CMake's install/packaging system to work seamlessly with
the built in archiving system which is what people use to prepare an
iOS app for submission to the App Store.


There is a bug I sometimes hit where the generated Xcode project
causes the "Indexing" phase to get stuck and I have to kill Xcode. And
when it happens to me, it keeps happening. This really scares me, but
I can't reliably reproduce it. Xcode 6 seems to have improved the
problem for me (so far).


For building libraries instead of applications, iOS 8 now has 3rd
party framework support (to support their new plugin system). I have
not tested this. But the framework layout is different than in Mac
(similar to how the .app bundle layout differs between iOS and Mac).
I'm guessing this will need to be adjusted in CMake. Also, FYI, flat
dylibs are not supported as far as I know...only frameworks.

Also, I think the @rpath stuff is still important, and I read that
Apple has now split the setting that was once the "install path" into
two separate entries, where the new entry is just for the rpath.
(Install path never made a lot of sense the way Apple does things
since there is never really an install path.)

Yes, it would be nice to build Universal binaries with simulator and
devices in the same fat binary, but Apple doesn't do this for you, and
I don't know if CMake should do this for you either. I saw on the
Xcode list, one senior Apple engineer was being difficult when pressed
on this issue. I think Apple is trying to leave open the possibility
that there could be an x86 device target some day, in which case it
would conflict with an x86 simulator target. Annoying. Currently, I
just lipo everything myself manually and say screw it.


Thanks,
Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/