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 isclearer about which architectures are supported (just in case someonedecides 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 withppc64 - 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.
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. Ronald[*] which won't be me, it seems that I'll be skipping the entire G5 generation
-bob _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
