[Python-ideas] Adding iOS/Android support to Python

[Ned Deily]

In article 
<CAJxq84_zofWVVGiin_JMO+aKuD9i2=6rZ9_R8WzOFnE4tZJ5zA at mail.gmail.com>,
 Russell Keith-Magee <russell at keith-magee.com> 
 wrote:
> On Sun, Oct 26, 2014 at 7:52 AM, Ned Deily <nad at acm.org> 
> wrote:
> > I have no personal experience with iOS builds but I *think* the
> > complexity of multi-arch builds is handled by the Apple-supplied
> > compiler tools in the same way for iOS as is done for OS X builds.
> That would be a nice if it were true, but unfortunately, it isn't AFAICT.
> 
> Under OS/X, to compile a single .c file, you make a single call to clang;
> if you reference an external library, you only need to point at a single
> library file. The system libraries provided by Apple are "fat", and contain
> multiple architectures.
> 
> If there's an analogous set of options for iOS, I haven't been able to find
> them. In particular, there's a very distinct split between the x86
> simulator libraries, and the ARM device libraries. In order to compile a
> fat iOS library, you have to do *at least* 2 compiles - one for i386, and
> one for ARM - because there are two completely separate - and incompatible
> - system libraries.
[...]
> It looks like it *might* be possible to compile the multiple *device*
> architectures (armv7, armv7s, arm64) on a single compile pass, but I
> haven't quite worked out the incantation yet. In the meantime, I'm having
> to do 5 complete builds (native, i386 simulator, armv7, armv7s, and arm64)
> to get a single library that can be used in a standalone project.

This is all really off-topic but, after a little bit of experimentation, 
I think it is the case that you can compile and link multiple iOS archs 
(armv7, armv7s, arm64) in a single cc/clang call just as you can for OS 
X archs; you just need to specify the proper sdk via xcrun (or the other 
supported methods) and the proper -arch values to clang.

One way:
xcrun --sdk iphoneos8.1 cc -arch arm64 -arch armv7 -arch armv7s -c test.c

But I think you are correct that it is not possible to do iOS builds and 
iOS simulators builds in one step as they are definitely different 
platforms from the tool chain perspective (just os OS X is a different 
platforms); I'm not sure how important that is.

$ xcodebuild -showsdks
OS X SDKs:
   OS X 10.9                        -sdk macosx10.9
   OS X 10.10                       -sdk macosx10.10

iOS SDKs:
   iOS 8.1                          -sdk iphoneos8.1

iOS Simulator SDKs:
   Simulator - iOS 8.1              -sdk iphonesimulator8.1

> On top of that, the OS/X build is self hosting - once you've compiled
> python.exe, you can use that executable to compile the python sources and
> to run the setup.py script that compiles module extensions. Netiher of the
> iOS builds are self hosting - you have to have a working native python
> compiler before you .

As I mentioned, there already is some, mostly undocumented support for 
cross-building with separation of build host tools from target host 
tools.  Presumably that could be extended as needed.

> > The main issue, as always, is getting buy-in to "standardize" support
> > for these platforms and all of the issues of long-term maintenance.
> > Applying a set of changes is just the first step.  We need to have
> > subject experts for code and documentation.  We'd need to have buildbots
> > to give some assurance that we aren't breaking things.   We need to have
> > people willing to test pre-releases.  All these things are doable and
> > probably desirable.  But they don't happen automatically.  The changes
> > that have already been added to the Python build system to support
> > various kinds of cross-builds are today largely undocumented,
> > unsupported by python-dev, and untested by our buildbots.  We need to
> > solve these problems for them as well before we end up with more bitrot.
> ... and that's what I've been trying to gauge with my post. I have a
> personal need for "Python on Mobile" support, and I don't think I'm alone
> in this. I can maintain a set of my own build tools and patch sets that
> provide Python support to my own satisfaction, but I think there's value in
> having that capability in Python's trunk.
> 
> However, I've got enough experience maintaining a large Open Source Python
> project to know that the story doesn't stop with submitting a patch that
> scratches my own itch - there's the long term maintenance to consider. And
> in this case, there's all the additional complications of getting testing,
> CI etc working on a mobile platform.
> 
> So - at the core of all of this is the big question: Should I bother? If I
> was to do the work, is the core team interested? And if so, what
> constitutes "the work" from Python's perspective? Is it just adding
> platform libraries and some patches to the build system to allow
> cross-platform builds for iOS and Android? Or do I need to clean up and
> document the entire cross-platform build system?

That's a really good question.  I'm not sure how you get an answer.  
Perhaps one approach is through producing a PEP and getting at least one 
core developer to champion it.  Guido's positive response is important.  
There would need to be some sort to consensus over on python-dev as 
well, I think.
 
> And a quick meta-question - Is there *any* documentation of the current
> build system? I've had a poke around, and I can't find anything that seems
> on topic. The "Setup and Usage' guide (or maybe the Windows FAW) is the
> closest I can find.

The Python Developer's Guide is probably the best place to start.  But 
you'll find very little about cross-building since, AFAIK, there are few 
core developers who are familiar with the topic.  Matthias Klose added 
the most recent cross-build changes.

https://docs.python.org/devguide/

-- 
 Ned Deily,
 nad at acm.org