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
2) Universal PythonLauncher
3) Revamped Mac/OSX/Dist scripts (probably should rewrite all that in
Python and not hardcode everything)
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.
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.
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.
-bob
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
