[Pythonmac-SIG] building universal binaries

[Bob Ippolito]

On Feb 4, 2006, at 2:57 AM, Ronald Oussoren wrote:

>
> On 4-feb-2006, at 11:16, Bob Ippolito wrote:
>
>>
>> On Feb 4, 2006, at 1:29 AM, Nicholas Riley wrote:
>>
>>> On Sat, Feb 04, 2006 at 09:41:32AM +0100, Ronald Oussoren wrote:
>>>> 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.
>>>
>>> This sounds like a good idea, and this is not just a legacy issue  
>>> with
>>> ppc64 - we'll likely have a 64-bit x86 Mac variant to handle within
>>> the year.
>>
>> Even more reason to leave fat as ppc,i386 -- which are all 32 bit
>> builds...  Currently, I'm pretty sure ppc64 won't even build at all.
>
> So what? "fat" or "universal" is ambigious, "i386,ppc" is not. That  
> seems a good
> reason to adapt the more verbose label to me, especially in the  
> context of setuptools.

fat or universal is not really ambiguous.  They mean i386,ppc in  
Apple terms.  The only other "supported" architecture is ppc64, and  
that can only speak POSIX and behaves completely differently.  I'll  
be very surprised (and annoyed) if they switch architectures again  
any time soon :)

When/if x86-64 happens, we'll just have to wait and see if they end  
up really supporting it, or shoving it off to the side like they do  
ppc64.  At some point a "MacPython 64bit" might make sense (for  
people doing really big number crunching), but it doesn't really make  
any sense to have that be universal because 64 bit apps on OS X can  
only really talk to libSystem.

> If someone were to donate a patch for a ppc64 universal build[*] it  
> will also
> require an architecture label, if it were to reuse 'fat' you'd get  
> two types of
> universal eggs: ones that support ppc64 and ones that don't.   
> That's no good if you
> want to support automatic installation, as setuptools does. An  
> explicit list of supported
> architectures is forward compatible and doesn't require more work  
> right now: just
> do a global substitute that replaces 'fat' by 'i386,ppc' and you're  
> done. Inserting
> logic that treats 'i386,ppc' can be done when adding the  
> hypothetical ppc64 build I
> mentioned earlier.

ppc64 is not going to happen universal.  It's a different Python with  
a different usage scenario and a different set of modules that are  
compatible with it.  If someone compiles a 64-bit Python they're  
going to have to do it separately (and mangle all of the checks for  
__APPLE__ and darwin because ppc64 is basically a pure POSIX beast  
with no frills).

> [*] which won't be me, it seems that I'll be skipping the entire G5  
> generation

I have a G5, but not one with > 4G of RAM to make use of :)

-bob