On Feb 21, 2005, at 4:16 AM, Roger Binns wrote:
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.
Did you read and understand the versioned frameworks blog entry I linked to? What you're saying has basically no relevance to what I said.
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).
The includes directory has never been the problem. This issue is only related to the linker, not the compiler.
Under certain circumstances, prior to Python 2.3.5/2.4.1, then extensions built on 2.3 would magically work for neither Python 2.3 or 2.4 because they were linked against the 2.4 dylib with 2.3 headers, so you'd get an API mismatch (which is a warning not a hard error, but still..).
No. The "-framework Python" link command was originally being used. It had the following problems:
(a) in Python 2.3.0-ish times, it was used without "-F". That meant the newest version Python in ~/Library/Frameworks or /Library/Frameworks would be preferred regardless of which Python you were using.
(b) in Python 2.3.1-ish times(?) it was used with "-F". That means that you were guaranteed to get the right Frameworks directory in play, but it would still link to the newest version of Python regardless of which one you are using.
(c) in Python 2.3.5 it links to the Python dylib directly, not utilizing any of GCC's search algorithms, and now does the right thing all the time.
Even with this, due to the way Mach-O works, it breaks an invariant that you have on other platforms: It's possible to share extensions between Pythons of the same major version (e.g. 2.3.x), regardless of where these Pythons are installed. When Python is built to target Mac OS X 10.3 or later using the "-undefined dynamic_lookup" linker flag, when using PantherPythonFix on 2.3.0, Python 2.3.5, or Python 2.4.x, then extensions are not even linked to the Python interpreter so this problem goes away and the invariant is preserved.
I understand your frustration in trying to understand the issues at hand here, but please know that they are tricky but solved. This topic comes up a lot and I'm pretty tired of talking about it.
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.
from <http://undefined.org/python/py2app.html>
- Make the application bundle standalone
- Since a typical Python application may have C library dependencies, such as
the Python interpreter itself, wxWidgets, etc. a second dependency resolution
pass occurs on the application bundle.
- Scan the application bundle for all Mach-O files (executables, shared libraries,
plugins, extensions, etc.).
- Read the load commands from every Mach-O file (using **macholib**) and build
a dependency graph.
- Copy in every dependent dylib (shared library) and framework that is not already
in the application bundle. Note that dylibs and frameworks in vendor locations
(``/System`` and ``/usr`` - except for ``/usr/local``) are NOT included in your
application bundle. This can include the Python interpreter, if you are using
a Python interpreter shipped with Mac OS X. Thus your application may be
"tightly bound" to a particular major version of Mac OS X if you are using
the vendor Python.
- Rewrite the Mach-O load commands such that the libraries know that
they have moved inside of an application bundle (i.e. using
[EMAIL PROTECTED] relative ids).
- Strip every Mach-O file of extraneous information (debugging symbols, etc.)
to save space. This may be disabled with ``--no-strip``.
-bob
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
