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

[Ned Deily]

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