[Pythonmac-SIG] Name that Python
Jack Jansen
Jack.Jansen@cwi.nl
Tue, 23 Jul 2002 13:01:36 +0200
On Monday, July 22, 2002, at 08:24 , Ronald Oussoren wrote:
>> root# install_name_tool -change Python.framework/Versions/2.3/Python
>> @executable_path/../Frameworks/Python.framework/Versions/2.3/Python
>> python
>> root# otool -Lv python python:
>> ...
>> @executable_path/../Frameworks/Python.framework/Versions/2.3/Python
>> (compatibility version 2.3.0, current version 2.3.0)
>
> If I understand this correctly you don't need to change anything on
> install if you include the modified copy of python as the python inside
> an application bundle with a local python framework.
>
> If you'd provide a python that is changed in this way as part of a
> 'normal' Python.framework install you could use this when building a
> python application with a local Python.framework instead of the python
> executable from Python.app. E.g. no need to use install_name_tool in
> BuildApplication, or even in the python installer (well except for 3th
> part .so modules, I haven't thought much about those).
I thought along these lines too, but then you can't get command line
Python to work anymore. Also, using the framework in embedding
applications and things like the Python scripting component would stop
working.
The functionality of install_name_tool shouldn't be too difficult to
duplicate in Python, the structure of MachO binaries appears to be
pretty straightforward (see /usr/include/mach-o for details). And
otherwise we would require the developer tools for full BuildApplication
support. Without the developer tools you would still get partial
support: BuildApplication can build an application that has all your
.pyc files in there but would depend on Python.framework.
--
- Jack Jansen <Jack.Jansen@oratrix.com>
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma
Goldman -