On 5-jan-05, at 1:08, Bob Ippolito wrote:
The problem we're trying to solve is that due to the way Apple's framework architecture works newer versions of frameworks are preferred (at link time, and sometimes even at runtime) over older ones.
Can you elaborate on that somewhat? According to
http://developer.apple.com/documentation/MacOSX/Conceptual/ BPFrameworks/Concepts/VersionInformation.html
there are major and minor versions of frameworks. I would think that every Python minor (2.x) release should produce a new major framework version of the Python framework. Then, there would be no problem.
Why does this not work?
It doesn't for reasons I care not to explain in depth, again.
But I do care:-) Specifically because I trust the crowd here to come up with good ideas (even if they're not Mac users:-).
Ronald already explained most of the problem, what it boils down to is that multiple versions of a framework can live in a single location. For most applications that's better than the old MacOS9 architecture (which I believe is pretty similar to the Windows dll architecture) because you can ship a single foo.framework that contains both version 1.2 and 1.3. There's also a symlink "Current" that will point to 1.3. At build time the linker will pick the version pointed at by "Current", but in the file it will record the actual version number. Hence, if you ship this framework new development will link to the newest version, but older programs will still load the older one.
When I did the framework python design I overlooked the fact that an older Python would have no way to specify that an extension would have to link against its own, old, framework, because on MacOS9 this wasn't a problem (the two had different filenames).
As an aside, I also overlooked the fact that a Python framework residing in /System could be overridden by one in /Library because in 2.3 we linked frameworks by relative pathname, because I simply didn't envision any Python living in /System for some time to be. The -F options could solve that problem, but not the 2.3 and 2.4 both in /Library problem.
The "new" solution is basically to go back to the Unix way of building an extension: link it against nothing and sort things out at runtime. Not my personal preference, but at least we know that loading an extension into one Python won't bring in a fresh copy of a different interpreter or anything horrible like that.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
