[Pythonmac-SIG] building universal binaries

[Bob Ippolito]

On Feb 3, 2006, at 11:41 AM, Bob Ippolito wrote:

>
> On Feb 3, 2006, at 11:01 AM, Ronald Oussoren wrote:
>
>>
>> On 3-feb-2006, at 20:00, Bob Ippolito wrote:
>>
>>>
>>> On Feb 3, 2006, at 10:52 AM, Ronald Oussoren wrote:
>>>
>>>>
>>>> On 3-feb-2006, at 5:23, Bob Ippolito wrote:
>>>>
>>>>> It fixes a couple of the endian issues in the Mac modules
>>>>> (platform.mac_ver, applesingle, gestalt, and the OSType
>>>>> converter functions)
>>>>
>>>> How do you convert four character codes? Is 'abcd' big endian or
>>>> platform-native?
>>>
>>> 'abcd' is platform endian.
>>
>> Fine by me. Either choice seems to be defendable that why I asked.
>>
>> BTW. I know next to nothing about SVK, can I use an ordinary
>> subversion client to fetch files from your repository?
>
> Yes, it works fine, the repo is just a subversion repo.  svk does all
> its magic in a few svn properties (keeping track of merge history
> basically).
>
> The advantage that SVK has in cases like this is that I can create a
> branch of python24-maint without using the svn.python.org repo
> directly and then have the capability to merge changes one way or
> another, while still using svn repositories.

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

1) 10.3.9 support
2) Universal PythonLauncher
3) Revamped Mac/OSX/Dist scripts (probably should rewrite all that in  
Python and not hardcode everything)

I'll probably take the pbproj out of PythonLauncher and just build it  
with the Makefile since it can inherit the right build flags and such  
that way.

In other words, this seems to work correctly universally:

$ mkdir _build
$ cd _build
$ ../configure --enable-framework --enable-universalsdk && make
$ sudo make frameworkinstall

The only backwards incompatible change (beyond missing WASTE,  
PythonIDE, PackageManager) that I'm aware of is the  
distutils.util.get_platform string:  it no longer says darwin, it  
says macosx-{ver}-{arch} where ver is the major.minor version of Mac  
OS X (not the damned kernel) and arch is either fat (universal is too  
long), ppc, i386, or whatever falls through from the uname.  And of  
course, if you're using the universal build, you'll need the 10.4u  
SDK installed to compile any extensions.

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

First and foremost this change fixes running-Python-in-the-build- 
directory-with-Rosetta, but the secondary benefit is that this  
metadata will show up in Cheese Shop if you build an egg with a  
universal Python.  Thus, this universal python will create fat eggs  
and will have a proclivity for fat eggs.  The potential issue here is  
that it might refuse to use single-arch eggs, which I don't see as  
much of a problem really.  If it didn't change the arch name to "fat"  
then you wouldn't be able to tell universal and single-arch eggs apart.

-bob