[Python-Dev] 2.5 open issues

["Martin v. Löwis"]

Guido van Rossum wrote:
>>       - bdist_deb in distutils package
>>         (Owner: ???)
>>         http://mail.python.org/pipermail/python-dev/2006-February/060926.html
> 
> Isn't that MvL?

I spoke in favour of including it, but don't recall ever to committing
as a "sponsor/second" of including it (and I certainly didn't write it).

I can't find a patch for bdist_deb right now, so if nobody steps forward
 with actual code to include, this gets probably dropped from 2.5. Notice
that the URL quoted actually speaks against a bdist_deb command.


>>       - Support for building "fat" Mac binaries (Intel and PPC)
>>         (Owner: Ronald Oussoren)
> 
> Yes, this would be cool.

This is nearly committed. For some reason, SF apparently dropped
my last change request for it, and Ronald's patch responding
to this request, so it barely missed 2.5a2. Regardless, I guess
Ronald will release his 2.5a2 binaries in the fat form.

For those interested, one surprising (for me) challenge in this
is that WORDS_BIGENDIAN can't be a configure-time constant
anymore. It doesn't need to be a run-time thing, either, because
at run-time, you know the endianness of the (current) processor.

It isn't configure-time constant, because each individual
gcc invocations runs *two* compiler passes (cc1) and *two*
assemblers, which incidentally have different endiannesses.

So WORDS_BIGENDIAN now must be a compile-time constant;
fortunately, gcc defines either __BIG_ENDIAN__ or __LITTLE_ENDIAN__,
depending on whether it is the PPC cc1 or the x86 cc1 that runs.

To make this work with autoconf on systems which don't
define either of these constants, pyconfig.h.in now has
a block that derives WORDS_BIGENDIAN from __(BIG|LITTLE)_ENDIAN__
if they are defined, and makes it configure-time otherwise.

So in short: WORDS_BIGENDIAN will always be right, and
will have two different values in a fat binary.

Regards,
Martin