
Guido van Rossum [guido@python.org] wrote:
I've been trying to understand how --with-next-framework is supposed to work, and on what systems it is supposed to work - with little success.
From what I understand, it will create a python2.0.dylib, and it will pass that to the linker when linking extension modules. Fine.
What confuses me is the snippet in Modules/getpath.c, where it somehow assumes that the Python library will live in an unversioned lib directory relative to the location of the Python framework. How is that supposed to work? Is anybody here willing to claim that this code is not entirely broken?
It's most likely broken. Which suggests that nobody has tried it in a *looooooong* time. I have no idea what the --with-next-framework option does, and I have no idea what a NeXT framework is.
A NeXT Framework is a way of building software on NeXTstep/OpenStep machines, and as far as I can tell, it continues largely unmodified on MacOS X (which is more OpenStep than MacOS at many layers). We just got our development copies of MacOS X here at Digital Creations, so we can take a look, but... as I recall, Jeffrey Shell wasn't able to get Python running without using these options.
Why are we still trying to support NeXT? Isn't it completely obsolete?
I know of a few dozen large organizations still on OpenStep, and with MacOS X I'd say it's far frrom obsolete, if anything it's more likely than ever to be a"strong platform".
I propose to rip out --with-next-framework and be done with it. If you feel --with-next-framework is worth having, feel free to propose platform-specific fixes to getpathp.c.
I think it should be auto-detected, there's just no reason not to. The uname of a MacOS X box is quite different than a Mac OX 9 box (which has no uname :-). Hopefully we can get a chance to look at this at work this week. Chris -- | Christopher Petrilli | petrilli@amber.org