On 23-mrt-2006, at 0:31, Andrew Barnert wrote:
> Thanks for the quick answers, and it's good to know
> that I'm not missing information right in front of my
> face....
>
> Me:
>>> First, what's up with ctypes and other things that
>>> need libffi?
>
> Ronald:
>> PyObjC contains a port of libffi to darwin/x86, but
> sadly
>> enough I didn't pay enough attention in the time
> between
>> WWDC'05 and the release of OSX/x86. My port of
> libffi
>> no longer works due to slight changes in the calling
>> conventions. I'll be fixing this shortly, and push
> those
>> upstreams and to ctypes.
>
> OK, I'll wait....
>
> By the way, I think I remember seeing some other
> project with a libffi port around the same time (late
> summer). Maybe pnet or mono or something related? Are
> you sharing changes, or just duplication each other's
> work? For that matter, is there anyone maintaining
> libffi itself, or is it just one of those many
> projects that Redhat abandoned and nobody's picked it
> up even though people still use it?
Libffi is part of the GCC source tree. I haven't tried
merging my port to darwin/x86 yet because of the general
hackishness of it at the time. Now that Apple has an
actual release of OSX/x86 I'll clean up my patch :-)
IIRC libffi is used in the java part of gcc (which isn't
used by Apple)
>
>>> Next, have the python24-fat changes been ported to
> the
>>> 2.5 trunk?
>
>> The changes have not been ported to the 2.5 tree
> yet,
>> but I intend to do so before the 2.5a1 release.
>
> OK. I can use a pure-Intel build to play around with
> 2.5 changes, but your 2.4 universal for actual
> development.
>
>>> How exactly are you supposed to properly install a
>>> framework build?
>
>> Just install using the pkg? My build script in the
>> python24-fat tree does a chmod after installing, but
>> that's mostly because its predecessor also did that.
>
> Yeah, that works, unless I want to try a patch, play
> with recent trunk changes, use different configure
> switches, install two different 2.4.2 versions in
> parallel, etc.
>
> I guess it's not that big a deal if you have to do
> some chmod/chgrp stuff to make frameworkinstall happy,
> since anyone who's going to install from source ought
> to be able to figure it out.
>
> What are the actual problems with having a root/wheel
> 755 framework directory instead of root/admin 775? I
> guess it means you can't install modules to
> site-packages out of .pkg files? If it's important, it
> would be nice if it were easier to do properly.
root/admin 775 makes it easier to install packages when
you're an admin user, you can do away with the call to
sudo.
>
> I'm guessing it would help the darwinports and fink
> guys out, too. Last I checked, fink wouldn't build
> Python at all on Intel, and darwinports wouldn't do a
> framework install--but even on PPC, they both ended up
> with a root/wheel 755 framework directory.
I don't use fink, and use darwinports only for unix-y tools,
IMHO neither should have to use framework installs :-)
>
>>> * test_curses is skipped, even though curses
> appears to work
>>> * all tests that require networking are skipped,
> even though
>>> at least some (maybe all) of the relevant
> modules work
>>> * test_re fails
>>> * test_{unicode,unicodedata,codecs} fail
>>
>> Dunno about these, they should work just fine. I
>> haven't tried building the trunk on an intel box yet
> though.
>
> I tested a few more things. So far, all of the skipped
> tests that I tried manually worked fine, and I'm not
> sure why they're skipped. All of the failed tests that
> I've tried actually are broken (like the
> u'\u2000'.isspace test I mentioned before). And I
> couldn't find bugs filed on any of them. Do people
> usually file bugs this early in the dev process?
According to buildbot (www.python.org/dev/buildbot/trunk)
the trunk shouldn't have any test failures.
>
> I might be able to figure some of these out; others,
> probably not. I know that a Unicode space is supposed
> to be a space, but when I disagree with the computer
> about how some regexp should be parsed, it's usually
> the computer that's right....
>
> So if I can't figure out the problems, should I at
> least gather the verbose test reports and file bugs?
>
>>> * test_{aepack,applesingle,macostools} fail
>>
>> Those are expected to fail, the python24-fat tree
>> contains bugfixes for this.
>
> OK, cool.
>
Ronald
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
