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

[Brett Cannon]

On Thu, Apr 15, 2010 at 04:41, Ned Deily <nad at acm.org> wrote:

> 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.
>

I know for me the reason I have never tried to help with building the
binaries is I simply lack the expertise. I always build straight UNIX
versions of Python under OS X, so I have no experience with framework builds
(which is what the binary distribution is). Heck, I didn't even know about
the build script until just now since it's such a pain to build. Plus I
don't know if you can use a framework build from within your svn checkout
for testing, so I REALLY don't bother building a framework. And to top it
off I use the latest libraries of things to look for possible breakage.

I am sure I am not the only person who has all of these barriers preventing
them from using a framework build consistently.


>
> 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.)
>
>
And this is another reason why Ronald has always been the only person to
build the OS X binary; it's complicated. Knowing how to get the proper
universal framework with the right things is annoying. Plus making sure
something works on multiple versions of OS X is a pain as I am sure very few
of us have 10.6, 10.5, and 10.4 lying around.

I mean if the build script was dead-simple run and forget I am sure many of
us would be willing to create dmgs. But it will take someone who knows what
is needed (sounds like Ned does and obviously Ronald does) to get it to that
place.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100415/94186725/attachment-0001.html>