[Python-Dev] Fwd: Broken link to download (Mac OS X) (original) (raw)

Ned Deily nad at acm.org
Thu Apr 15 13:41:03 CEST 2010

In article <4BC697D2.4020200 at v.loewis.de>, "Martin v. Lowis" <martin at v.loewis.de> wrote:

Greg Ewing wrote: > Michael Foord wrote: >> Building Python requires, I believe, the XCode development tools to be >> installed. Even then, building a full version of Python - with all >> the C extensions that are part of a Python release - is not a trivial >> task. > What's non-trivial about it? Building a DMG file, in a way that the output will actually work on most other systems.

As Ronald pointed out, the installer build script does all of the dirty work of building the install disk image (the .dmg file), including downloading and building necessary third-party libraries. What isn't automatically checked at the moment is that the third-party Tk framework is in place during the build and that there isn't contamination from the build user's environment. There is a patch in Issue5651 to do much of that. It doesn't currently try to handle the possibility of MacPorts (/opt/local) and Fink (/sw) contamination. I believe that issue should be addressed by the resolution of Issue7713.

Keep in mind that Python on OS X supports the standard OS X multi-architecture (Intel vs PPC and/or 32-bit vs 64-bit executables in the same file) and multi-version features (the current installer builds are fully supported on 10.6, 10.5, and 10.4 and "best-effort" supported on 10.3 as well although building is not supported on 10.3) as well as "Unix" shared library vs OS X framework shared library configurations.
That leads to a rather imposing matrix of potential build systems vs potential target systems. For the most part, Apple provides excellent upward compatibility; downward is somewhat trickier. OS X 10.6 (Snow Leopard) has complicated matters by the change to preferring 64-bit building and executing where possible. For python builds, some build configurations that worked by default under 10.5 and earlier no longer do so on 10.6, primarily due to standard library modules that depend on APIs, in many cases deprecated ones, that are only available in 32-bit versions. The old Macintosh modules comprise the biggest group of these and, while they have been removed in 3.x, they still remain in 2.x. But there are some others as well, which explain most of the build issues Michael reported. There are also newer versions of some open source libraries in 10.6 which cause problems for multi-version builds: openssl, for one, and Apple's 64-bit version of Tk 8.5.

None of these problems are insolvable but with the very limited resources (i.e. people time) we've had for working on these issues, and when there have been so many other more critical problems, it has been easier up to now to stick with building on 10.5 (or even on 10.4 which I test build occasionally). I think the single most important thing that can be done to help right now is to get a robust system of OS X buildbots going so that many of the critical problems can be detected up front rather than when one of us gets around to building and install testing the multi-arch and multi-version installers. Since there are so many potential configurations, some thought needs to go into which would be of the most value. I would say that the most important build configurations are: (1) 32-bit Intel/PPC framework on 10.5 (and eventually 10.6) targeted for 10.3 through 10.6 (the current installer config setup); and (2) 32-/64- Intel-only framework for 10.6; followed by (3) 32-/64- Intel/PPC framework for 10.5 and 10.6. Building the whole installer and testing on as many targeted systems as possible would be ideal but that adds more complexity to the automation (again, not insurmountable). But even just doing framework multi-arch builds, installs, and tests (using the appropriate options) on only the build systems themselves without building an installer or third-party libs would go a long way towards catching many, if not most, problems early.
I'd be happy to supply more detailed suggestions for specific configuration parameters for those interested in setting up buildbots.
(There may be some delay, though, as I will have limited time and Internet access for the next three weeks.)

-- Ned Deily, nad at acm.org

More information about the Python-Dev mailing list