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 frameworkinstallThe 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-fatFirst 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
