pkg_resources and Mac OS X universal builds
Modern Mac OS X applications need to support both the i386 and ppc architectures in what's called a universal build (AKA fat in NeXT- ese). Ronald Oussoren and I are very far along in making python24- maint capable of doing this with patches all over the build procedure and a few smaller patches to distutils itself. One such patch basically expands upon the macosx platform string from pkg_resources, with the additional clause that a fat build of Python (one configured to build multi-architecture extensions) will report its architecture as "fat" rather than "i386" or "ppc". In order for setuptools' pkg_resources to inherit this behavior, I need the attached patch to be accepted. Basically it just skips over the custom behavior if get_platform already returns a sanitized value. -bob
At 02:50 PM 2/3/2006 -0800, Bob Ippolito wrote:
Modern Mac OS X applications need to support both the i386 and ppc architectures in what's called a universal build (AKA fat in NeXT- ese). Ronald Oussoren and I are very far along in making python24- maint capable of doing this with patches all over the build procedure and a few smaller patches to distutils itself. One such patch basically expands upon the macosx platform string from pkg_resources, with the additional clause that a fat build of Python (one configured to build multi-architecture extensions) will report its architecture as "fat" rather than "i386" or "ppc".
In order for setuptools' pkg_resources to inherit this behavior, I need the attached patch to be accepted. Basically it just skips over the custom behavior if get_platform already returns a sanitized value.
Implemented in SVN rev 42231.
With the way that we're returning the distutils platform on the universal branch of Mac OS X, we need another patch to pkg_resources. The reason for this is that distutils.util.get_platform() returns the platform that it is trying to produce binaries for, which is often not the exact current platform. More specifically, our current strategy is to produce a version of Python that will build extensions that are compatible with Mac OS X 10.3, but the actual building of extensions requires Mac OS X 10.4 or later (because the toolchain doesn't exist on Mac OS X 10.3). In some rare cases, people will want to produce packages that explicitly require Mac OS X 10.4 or later, which they can do by setting the MACOSX_DEPLOYMENT_TARGET=10.4 environment variable when running setup.py. This will influence the value returned by disutils.util.get_platform(), and will influence the compiler and linker if extensions are built. This patch adds an internal _get_max_platform(plat) function that returns the actual runtime version of Mac OS X, for use in compatible_platforms. -bob
On Feb 5, 2006, at 2:00 PM, Bob Ippolito wrote:
With the way that we're returning the distutils platform on the universal branch of Mac OS X, we need another patch to pkg_resources. The reason for this is that distutils.util.get_platform() returns the platform that it is trying to produce binaries for, which is often not the exact current platform. More specifically, our current strategy is to produce a version of Python that will build extensions that are compatible with Mac OS X 10.3, but the actual building of extensions requires Mac OS X 10.4 or later (because the toolchain doesn't exist on Mac OS X 10.3).
In some rare cases, people will want to produce packages that explicitly require Mac OS X 10.4 or later, which they can do by setting the MACOSX_DEPLOYMENT_TARGET=10.4 environment variable when running setup.py. This will influence the value returned by disutils.util.get_platform(), and will influence the compiler and linker if extensions are built.
This patch adds an internal _get_max_platform(plat) function that returns the actual runtime version of Mac OS X, for use in compatible_platforms.
Oops, wrong patch.. here's the correct one. Sorry about that: -bob
At 02:07 PM 2/5/2006 -0800, Bob Ippolito wrote:
On Feb 5, 2006, at 2:00 PM, Bob Ippolito wrote:
With the way that we're returning the distutils platform on the universal branch of Mac OS X, we need another patch to pkg_resources. The reason for this is that distutils.util.get_platform() returns the platform that it is trying to produce binaries for, which is often not the exact current platform. More specifically, our current strategy is to produce a version of Python that will build extensions that are compatible with Mac OS X 10.3, but the actual building of extensions requires Mac OS X 10.4 or later (because the toolchain doesn't exist on Mac OS X 10.3).
In some rare cases, people will want to produce packages that explicitly require Mac OS X 10.4 or later, which they can do by setting the MACOSX_DEPLOYMENT_TARGET=10.4 environment variable when running setup.py. This will influence the value returned by disutils.util.get_platform(), and will influence the compiler and linker if extensions are built.
This patch adds an internal _get_max_platform(plat) function that returns the actual runtime version of Mac OS X, for use in compatible_platforms.
Oops, wrong patch.. here's the correct one. Sorry about that:
I've implemented a similar - but different - patch. Yours causes setuptools' tests to fail on non-Mac platforms, including non-Mac darwin.
On Feb 7, 2006, at 5:37 AM, Phillip J. Eby wrote:
At 02:07 PM 2/5/2006 -0800, Bob Ippolito wrote:
On Feb 5, 2006, at 2:00 PM, Bob Ippolito wrote:
With the way that we're returning the distutils platform on the universal branch of Mac OS X, we need another patch to pkg_resources. The reason for this is that distutils.util.get_platform() returns the platform that it is trying to produce binaries for, which is often not the exact current platform. More specifically, our current strategy is to produce a version of Python that will build extensions that are compatible with Mac OS X 10.3, but the actual building of extensions requires Mac OS X 10.4 or later (because the toolchain doesn't exist on Mac OS X 10.3).
In some rare cases, people will want to produce packages that explicitly require Mac OS X 10.4 or later, which they can do by setting the MACOSX_DEPLOYMENT_TARGET=10.4 environment variable when running setup.py. This will influence the value returned by disutils.util.get_platform(), and will influence the compiler and linker if extensions are built.
This patch adds an internal _get_max_platform(plat) function that returns the actual runtime version of Mac OS X, for use in compatible_platforms.
Oops, wrong patch.. here's the correct one. Sorry about that:
I've implemented a similar - but different - patch. Yours causes setuptools' tests to fail on non-Mac platforms, including non-Mac darwin.
Could you explain how? I don't see it. The condition is:: if m is not None and sys.platform == "darwin": ... How does that fail on pure Darwin? The condition should be False because m has to be None at that point and the branch shouldn't happen. -bob
At 11:48 AM 2/7/2006 -0800, Bob Ippolito wrote:
On Feb 7, 2006, at 5:37 AM, Phillip J. Eby wrote:
I've implemented a similar - but different - patch. Yours causes setuptools' tests to fail on non-Mac platforms, including non-Mac darwin.
Could you explain how? I don't see it. The condition is::
if m is not None and sys.platform == "darwin": ...
Note that that's because I added the "darwin" check; it wasn't in your original patch.
How does that fail on pure Darwin? The condition should be False because m has to be None at that point and the branch shouldn't happen.
You're making the assumption that platform compatibility checks between Mac OS X version strings only happen when you're *running* on Mac OS X, but the test suite contains tests for the platform compatibility checking code that runs on all platforms. Thus, the "m is not None" condition can apply regardless of platform, at least for test purposes.
participants (2)
-
Bob Ippolito -
Phillip J. Eby