They are NOT AT ALL designed to be able to facilitate writing software that links against a previous version.
With BitPim on Windows and Linux, the Python interpretter is distributed as part of the binary package. There is absolutely no dependencies on what the user's system has, except base C and X libraries.
The build machine uses the standard Python and wxPython binary distributions for the relevant platform, which means that the same binaries as are used by thousands of other users are used.
Consequently there is a very high confidence in the binary distributed app.
I can also have multiple versions of Python installed on developer machines.
Extensions have to be compiled against each version and are installed in
the corresponding site-packages directory. I've never tried moving the Pythons after installation and have no idea if it would work or not,
and don't care if it doesn't.
However, it's common to have Python 2.3 and Python 2.4 installed and want to be able to link new software against 2.3, so the default framework mechanisms are not suitable for this.
If you use distutils on other platforms, it uses the directory it corresponds to. For hand built stuff, you can do something similar:
INCLUDEDIR=`python -c "import distutils.sysconfig; print distutils.sysconfig.get_python_inc()"`
I am still baffled as to what problem is being solved. Are you trying to allow extensions built against Python 2.3 to magically work on 2.4. (That isn't even possible under Windows and unlikely on Linux).
It also looks like py2app doesn't include the Python interpretter. Is that the case? Is that the cause of all these issues? Is there any reason not to include the Python interpretter? From a software quality standpoint, I definitely want the exact Python interpretter from the build machine to be redistributed along with the binary app.
Roger _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
