<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 26, 2014 at 7:52 AM, Ned Deily <span dir="ltr"><<a href="mailto:nad@acm.org" target="_blank">nad@acm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In article <<a href="mailto:AF04D1E2-058D-4322-91C7-E544E837A1D7@yahoo.com">AF04D1E2-058D-4322-91C7-E544E837A1D7@yahoo.com</a>>,<br>
 Andrew Barnert<br>
<span class=""> <abarnert@yahoo.com.dmarc.invalid> wrote:<br>
> On Oct 24, 2014, at 19:20, Russell Keith-Magee<br>
> <<a href="mailto:russell@keith-magee.com">russell@keith-magee.com</a>> wrote:<br>
</span><span class="">> > Given three independent platform-specific build directories, it's<br>
> > relatively easy to construct a "fat" framework, but it isn't clear to me<br>
> > how that would fit into Python's build system. I can see that the build<br>
> > system has support for "universal" builds, which looks like an artefact of<br>
> > the OS X PPC->i386 conversion, but the build approach appears to be<br>
> > different to that required for iOS.<br>
><br>
> It's still perfectly possible to build Python universal on OS X. In fact,<br>
> both the <a href="http://python.org" target="_blank">python.org</a> builds and Apple's pre-installed builds are fat<br>
> i386/x86_64.<br>
><br>
> iOS does put some limitations on things, especially when building shared<br>
> libs, but if you need to fall back to building each target separately and<br>
> lipo'ing them together manually, I'm pretty sure there are a few third-party<br>
> libs that already use that workaround. Didn't PyObjC used to build that way?<br>
<br>
</span>I have no personal experience with iOS builds but I *think* the<br>
complexity of multi-arch builds is handled by the Apple-supplied<br>
compiler tools in the same way for iOS as is done for OS X builds.  </blockquote><div><br></div><div>That would be a nice if it were true, but unfortunately, it isn't AFAICT.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><div>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 .</div></div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I<br>
assume that, like for OS X builds, the compiler driver handles the<br>
multiple builds and lipos automatically under the covers based on the<br>
requested archs, the SDK, and platform tools in use.  As Andrew notes,<br>
we have long fully supported SDK builds and all of the universal archs<br>
for OS X (again using Apple's compiler chain distributed via Xcode<br>
and/or the Command Line Tools).  I wouldn't expect that to be a big<br>
problem to adapt for iOS.  (Cross building on platforms other than OS X<br>
is another matter.)<br>
<br>
The main issue, as always, is getting buy-in to "standardize" support<br>
for these platforms and all of the issues of long-term maintenance.<br>
Applying a set of changes is just the first step.  We need to have<br>
subject experts for code and documentation.  We'd need to have buildbots<br>
to give some assurance that we aren't breaking things.   We need to have<br>
people willing to test pre-releases.  All these things are doable and<br>
probably desirable.  But they don't happen automatically.  The changes<br>
that have already been added to the Python build system to support<br>
various kinds of cross-builds are today largely undocumented,<br>
unsupported by python-dev, and untested by our buildbots.  We need to<br>
solve these problems for them as well before we end up with more bitrot.</blockquote><div><br></div><div>... 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. </div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>Yours,</div><div>Russ Magee %-)</div><div><br></div></div></div></div>