[Pythonmac-SIG] building universal binaries

[Bob Ippolito]

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.

The "only" thing that needs to be done is to change strings in these  
files during (or after I guess) frameworkinstall:

OSX/Dist/resources/ReadMe.txt
OSX/Dist/resources/Welcome.rtf
OSX/PythonLauncher/PythonLauncher_app/Contents/Info.plist
OSX/PythonLauncher/PythonLauncher_app/Contents/Resources/ 
factorySettings.plist
OSXResources/framework/Info.plist
OSXResources/framework/version.plist
OSXResources/framework/InfoPlist.strings

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

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.

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.

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

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.

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

-bob