Haunted by an ancient post about iPhone cross-compilation and CMake-based builds

posted Jun 26, 2011, 7:14 PM by Michael Safyan   [ updated Feb 19, 2012, 2:07 PM ]
Since I put up the email form on my main page, about 90% of the emails I receive from there are related to two ancient posts about the iPhone that I have since deleted. I've grown a bit tired of answering each such email individually, so I'll explain why I deleted those articles, my updated recommendations, and a link if you really want to go down the paths of those articles.

Incredibly Ancient

The aforementioned posts were written at the time of iPhoneOS 3.0 and iPhoneOS 3.1, which predates Apple's rebranding of iPhoneOS to iOS. When iPhoneOS 3.2 was released, the snippets provided in those posts ceased to work without substantial modification. Needless to say, the methods outlined are incredibly fragile and a huge burden to maintain. Therefore, I generally would not recommend using this mechanism and instead suggest just using Xcode, since xcodebuild makes it possible to build the project from the commandline, and Xcode projects are far less likely to be broken by Apple updating their toolchain than the CMake-based project being broken by those same updates.

Incorrect Premise

The posts are based on the premise that one should obtain code reuse by cross-compiling the same bit of code. This is generally not the best way to achieve reuse, especially not with mobile devices. The best way to obtain reuse is by making the logic available through a RESTful web service, and simply making the user interface a light-weight wrapper to this shared logic (or, in some cases, just a very simple UIWebView to a web-based user-interface that is built on top of that shared web service logic). As an example, it makes a whole lot more sense to compile a support-vector-machine library on a Linux-based server and provide a web service to some sort of classification built on top of it than it would be to attempt to cross-compile that library on the iPhone and attempt to run that same piece of code directly on the iPhone hardware. Not only is cross-compilation a huge pain, but a lot of logic when run directly on a mobile devices performs poorly compared to its performance on a server (or possibly on lotsa servers all in parallel!), and doing so consumes more battery power than a simple HTTP call.

Yeah, Yeah. Ok, Where are the Articles?

The articles have been obliterated, but for the CMake-based iPhone compilation, some traces still exist in the libpnx project for which I began searching for how to create a CMake-based iPhone project in the first place. There are two key pieces: a configuration script which configures CMake and a special toolchain file used in the configuration. Each version of iPhoneOS requires two configuration scripts and two toolchain files, corresponding to the device itself and to the simulator. The various configuration scripts can be seen in the trunk directory. Their corresponding toolchain files may be found in the tools/share/cmake directory. Building an iPhone framework from the result required combining the device and simulator versions of the library using lipo and then copying (and renaming) the library file, along with the header files into a *.framework folder that is structured identically to that of the other iPhone frameworks (if I remember correctly, the library had to have the same name as the basename of the .framework, and the headers needed to go in a "Headers" subfolder). Again, I don't recommend that you do this, but if you were really curious as to how that was done, that is the gist of it. All that work, though, could easily be saved by just dumping the code directly into Xcode.

What About the Cross-Compilation Article?

It wasn't really an article so much as a really, really long commandline invocation to the "./configure" program that only worked for cross-compiling the Apache Portable Runtime. This invocation is not generally applicable to other programs, and it probably would not have worked on later versions of APR. Again, I don't recommend trying to figure out how to cross-compile autoconf-based projects. Either compile it on a server and offer a set of its functionality over the web, or dump the necessary sources directly into your Xcode project.