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?
> > 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.
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.
> > * 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?
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.
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
