[Pythonmac-SIG] building universal binaries

Ronald Oussoren ronaldoussoren at mac.com
Sun Feb 5 15:48:36 CET 2006


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 :-)

>
>> 2) Universal PythonLauncher
>
> This is done.
>
>> 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.

>
>> This backwards incompatible change is mostly just a backport from
>> setuptools' pkg_resources module.
>>
>> $ python -c "from distutils.util import get_platform as p; print p()"
>> macosx-10.4.3-fat
>
> 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).

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

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2157 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060205/d8cbc808/attachment.bin 


More information about the Pythonmac-SIG mailing list