What is --with-next-framework
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? Regards, Martin
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. Why are we still trying to support NeXT? Isn't it completely obsolete? 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. --Guido van Rossum (home page: http://www.python.org/~guido/)
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
Guido van Rossum [guido@python.org] wrote:
[Argument for the continued viability of OpenStep noted.]
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.
Hm... That might not get there in time for the 2.0 Release Candidate, and after that it's an absolute code freeze (with exceptions only for showstopper bugfixes) until 2.0 is released.
I guess MacOS X itself is still in beta, so we can afford to require the creation of additional patches to fully support it after 2.0 is released.
MacOS X is in beta until Q1 (and I'd bet the END of Q1), so if there's a 2.1 planned sometime around there, which I believe there is, then it'd be fine to roll it into that level in my opinion. Chris -- | Christopher Petrilli | petrilli@amber.org
[Argument for the continued viability of OpenStep noted.]
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.
Hm... That might not get there in time for the 2.0 Release Candidate, and after that it's an absolute code freeze (with exceptions only for showstopper bugfixes) until 2.0 is released. I guess MacOS X itself is still in beta, so we can afford to require the creation of additional patches to fully support it after 2.0 is released. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (4)
-
Christopher Petrilli -
Christopher Petrilli -
Guido van Rossum -
Martin v. Loewis