On Feb 11, 2005, at 12:34, Roger Binns wrote:
Yeah, if you want to use a non-system Python with an extension built with the system Python there are some potential issues.
Is there a page somewhere that actually explains what all this terminology is about (eg Framework, alias bundles and similar).
Framework, Application Bundle, etc. is all described at developer.apple.com. Alias bundle is py2app terminology, the only documentation I've written for it beyond what made it to this list and what's in --help is in the PyObjC tutorial: http://pyobjc.sourceforge.net/doc/tutorial.php
Basically, an alias bundle is for development only, and is roughly similar in purpose to Xcode's ZeroLink feature. Instead of scanning your applications for dependencies, rewriting Mach-O headers, etc. it rigs an application bundle such that it runs directly out of your source directory and your development environment, making symlinks and aliases where necessary, so you can have a really quick edit/run cycle. You only have to build the alias bundle once, unless you add additional data files that need to be symlinked into the bundle.
I am used to the Python files and libraries just existing in a conventional filesystem. Nothing complicated. All very trivial. Multiple versions can be installed. A simple --prefix can move where it is in ./configure. Each one is an island with no possibility of sharing extensions or modifications between them. (That is a very good thing - keeps it simple.) wxPython does have some dynamic linking issues on Unix (it hard codes the path to the wxWidgets directory at the ELF level, but chrpath fixes that.)
Frameworks and application bundles are an extension to this concept.
py2app operates at the Mach-O level (roughly equivalent to ELF) and automatically locates all link-time dependencies and does the equivalent of chrpath so that they work in the application bundle.
This failure was probably due to the fact that you were not using py2app at the time.
We used to use bundlebuilder. So it sounds like there is 99.999% chance
we won't have to do seperate 10.4 builds. Unless we do things like
hook into SpotLight ....
It's totally possible to build your software such that it detects the version of Mac OS X at runtime and enables/disables functionality. This is common practice. If you are using a Mac OS X 10.2 compiled version of PyObjC and you run it on Mac OS X 10.3, you will simply see more classes and new functionality on existing classes. The correct way to determine if the functionality exists is to simply see if the class is there or the class responds to new methods.
-bob
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
