[issue23670] Modifications to support iOS as a cross-compilation target

Russell Keith-Magee report at bugs.python.org
Thu Apr 16 04:01:46 CEST 2015


Russell Keith-Magee added the comment:

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.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________


More information about the Python-bugs-list mailing list