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

[Russell Keith-Magee]

On Sun, Oct 26, 2014 at 7:52 AM, Ned Deily <nad at acm.org> wrote:

> In article <AF04D1E2-058D-4322-91C7-E544E837A1D7 at yahoo.com>,
>  Andrew Barnert
>  <abarnert at yahoo.com.dmarc.invalid> wrote:
> > On Oct 24, 2014, at 19:20, Russell Keith-Magee
> > <russell at keith-magee.com> wrote:
> > > Given three independent platform-specific build directories, it's
> > > relatively easy to construct a "fat" framework, but it isn't clear to
> me
> > > how that would fit into Python's build system. I can see that the build
> > > system has support for "universal" builds, which looks like an
> artefact of
> > > the OS X PPC->i386 conversion, but the build approach appears to be
> > > different to that required for iOS.
> >
> > It's still perfectly possible to build Python universal on OS X. In fact,
> > both the python.org builds and Apple's pre-installed builds are fat
> > i386/x86_64.
> >
> > iOS does put some limitations on things, especially when building shared
> > libs, but if you need to fall back to building each target separately and
> > lipo'ing them together manually, I'm pretty sure there are a few
> third-party
> > libs that already use that workaround. Didn't PyObjC used to build that
> way?
>
> 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.

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 .

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.

I
> assume that, like for OS X builds, the compiler driver handles the
> multiple builds and lipos automatically under the covers based on the
> requested archs, the SDK, and platform tools in use.  As Andrew notes,
> we have long fully supported SDK builds and all of the universal archs
> for OS X (again using Apple's compiler chain distributed via Xcode
> and/or the Command Line Tools).  I wouldn't expect that to be a big
> problem to adapt for iOS.  (Cross building on platforms other than OS X
> is another matter.)
>
> 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?

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.

Yours,
Russ Magee %-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141026/6757fc78/attachment-0001.html>