Message241189
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. |
|
Date |
User |
Action |
Args |
2015-04-16 02:01:46 | freakboy3742 | set | recipients:
+ freakboy3742, doko, ronaldoussoren, ncoghlan, ned.deily, r.david.murray, bkabrda, rkuska |
2015-04-16 02:01:46 | freakboy3742 | set | messageid: <1429149706.71.0.849434170601.issue23670@psf.upfronthosting.co.za> |
2015-04-16 02:01:46 | freakboy3742 | link | issue23670 messages |
2015-04-16 02:01:45 | freakboy3742 | create | |
|