[Pythonmac-SIG] building universal binaries

[Ronald Oussoren]

On 3-feb-2006, at 21:10, Bob Ippolito wrote:

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

I have that, although the patches are gross.

> 2) Universal PythonLauncher

> 3) Revamped Mac/OSX/Dist scripts (probably should rewrite all that  
> in Python and not hardcode everything)

I have started on this as well, including code to download a build  
universal binaries for readline and sleepycat db.

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

That seems to be the correct way forward, the project file isn't  
helpful here.

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

The first one seems unacceptable, there's no change that this will  
get merged into python 2.4.3. It would be nice to get this into  
python 2.5 though. This will not stop me from using your build though.

The requirement on the 10.4u SDK means you won't be able to build  
extensions on 10.3.

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

An alternative to fat might be 'ppc,i386'. That is longer, but is  
clearer about which architectures are supported (just in case someone  
decides to donate support for a threeway universal build). Patching  
setuptools to know that an architecture string that contains a comma  
is actually a list of architectures shouldn't be too hard.

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/20060204/4dd36aa0/attachment.bin