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

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.

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
the architecture calls from the default compile flags.

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

-------------- 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/c6523fa3/attachment-0001.bin