Re: [Pythonmac-SIG] building universal binaries

[Ronald Oussoren]

On 5-feb-2006, at 19:59, Bob Ippolito wrote:

On Feb 5, 2006, at 6:48 AM, Ronald Oussoren wrote:

On 5-feb-2006, at 7:46, Bob Ippolito wrote:

On Feb 3, 2006, at 12:10 PM, Bob Ippolito wrote:

I think the only things missing from my branch currently are:

1) 10.3.9 support

I believe this is taken care of now that Ronald contributed the weak linking patch.

If anyone wants support for 10.3.x with x <= 8 now would be the right time to speak up and volunteer resources :-)

In py2app I should at least be able to give a good error dialog if the app is built with the fat build but the target OS isn't >= 10.3.9, so this isn't all that urgent...

3) Revamped Mac/OSX/Dist scripts (probably should rewrite all that in

Python and not hardcode everything)

This isn't done yet, but what we have now is probably a fully usable universal Python.

I'll work on this, I probably still know what needs to be done from when I tried to build a Python 2.4.2 compatible package using this script.

OSX/Dist/resources/ReadMe.txt
OSX/Dist/resources/Welcome.rtf
OSX/PythonLauncher/PythonLauncher_app/Contents/Info.plist

OSXResources/framework/Info.plist
OSXResources/framework/version.plist
OSXResources/framework/InfoPlist.strings

The "only" thing that needs to be done is to change strings in these files during (or after I guess) frameworkinstall: OSX/PythonLauncher/PythonLauncher_app/Contents/Resources/ factorySettings.plist I was thinking it would be easiest to use string.Template to do this, with a dict populated mostly with distutils.sysconfig information but with a couple extra strings added such as the architectures supported, the full version, and the size of the package after installation.

This backwards incompatible change is mostly just a backport from
setuptools' pkg_resources module.


macosx-10.4.3-fat

$ python -c "from distutils.util import get_platform as p; print p()"

This output will now be:
macosx-10.3-fat

The version number is determined from MACOSX_DEPLOYMENT_TARGET (or CONFIGURE_MACOSX_DEPLOYMENT_TARGET). It's relatively safe to assume that modules compiled with this build will be compatible with Mac OS X 10.3.9 (as long as they don't use 10.4 specific features anyway).

I'm not 100% sure I'm happy with this. You can now accidently create binary packages that claim to run on 10.3 yet don't. But as you say, this will likely affect only a very small number of packages (PyObjC being one of those, that's on my TODO list already).

The only way to check this would be to set MACOSX_MAX_VERSION_REQUIRED to 1030, but that would be bad too because then you couldn't write code that takes advantage of Mac OS X 10.4 features because you'd get a compile time error.

Let's just keep the current behaviour (that is packages claiming that they'll run on 10.3), we can always change this if it turns out that this is a problem. Neither of expects it will be a problem, so we should be safe ;-)

In the setuptools branch of PyObjC the 10.3 and 10.4 specific modules are in separate distributions. We could simply set MACOSX_DEPLOYMENT_TARGET to 10.4 in the 10.4 setup.py and then it should build a package that claims 10.4.

I want to use weak linking in the wrappers to ensure that a single binary distribution will be useable on 10.3 and later without loosing features. That's not rocket-science, but requires some work.

For modules that absolutely require 10.4 you can set the MACOSX_DEPLOYMENT_TARGET environment variable at build time (e.g. in setup.py) and then the package produced will have a different platform string. setuptools will need work if people actually do this, because it will need to know that a Mac OS X 10.4 user can use "macosx-10.3-fat" and "macosx-10.4-fat" packages. It's probably a better idea to just write all your code so that it uses weak symbols for anything that isn't in 10.3 and raises ImportError on initialization if it's not usable.

Setuptools already contains code for this (using 10.3 packages on 10.4) in pkg_resources.compatible_platforms for the stock python distribution. That should also work with the python24-fat tree. The only thing that would require work is accepting a cpu-specific version if a fat package is not available. The only reason that might be useful is stuf like psyco which is only available for one of cpu-type.

Well the way everything is setup, it's not going to be reasonable to build a package that claims to be specific to a given architecture using the universal Python. We'd need to have Yet Another Distutils Hack that takes the architecture list off of the command line or something and modifies the compiler/linker flags.. ick.

the architecture calls from the default compile flags.

Time for a MacOSXCompiler class? The hack would have to look at extra_compile_args and extra_link_args, if those contain '-arch' arguments it should strip

We do still need to patch setuptools because distutils.util.get_platform() is going to say 10.3, so we'd need to insert the code that knows what the actual version of the OS is.

If you need to specify another platform you can use a setuptools- specific argument in setup.py.

I can't think of anything that only works on one architecture... even psyco has a C-based ivm that makes some smaller optimizations on non-x86 platforms...

Yet another thing not to worry about then :-)

Ronald

-bob

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig