homepage

Hi Matthias:
 * The libffi situation on iOS is much the same as it is on OS/X - it needs to be pre-generated. This can't be driven by the existing build system - libffi's Makefile requires a separate pre-generation step. There's certainly potential for reuse between the OS/X and iOS generated files, though - there's no reason I couldn't merge the libffi_ios tree into the libffi_darwin tree - they reuse a lot of the same code for the x86-64 platform.
 * Regarding Setup.* - if shipping specific Setup.* files is a problem, I can certainly look at enhancing the makesetup process to generate these, rather than shipping generated files. 
 * I'll add a comment to the setup.py change. Essentially, it's an edge case of the current setup.py - if you don't have *any* external modules, the current logic breaks evaluating the size of the columns to use when displaying external modules that haven't been compiled - although it's displaying the list of *missing* modules, it uses the longest name in the *existent* extensions to determine the display column width.
 * The Plat_ios constants certainly appear to be the same for all platforms; admittedly, though, I haven't done a thorough audit of this. I'll put this on my todo list.
 * The build triples are "armv7-apple-ios" for older 32 bit iOS devices, "aarch64-apple-ios" for newer 64 bit devices, and "x86_64-apple-ios" on the simulator. Builds for "armv6-apple-ios" and "armv7s-apple-ios" are also plausible, but armv7 and aarch64 is what XCode supports as a default configuration at present.