[Pyobjc-dev] execing /usr/bin/python

[Ronald O. <ous...@ci...>]

On Thursday, Oct 31, 2002, at 14:20 Europe/Amsterdam, bb...@ma... 
wrote:
>
>> 2. If not, how could this be implemented?
>
> It is is implemented by:
       - The python sources are copied to the Resources directory of the 
application

Do we have any control over this? I'd like to be able to convert the 
sources to bytecode (slightly faster startup, and this makes it harder 
to change the code).

>
>     - using a series of copy file phases to copy the PyObjC module 
> into the 'pyobjc' subdirectory of the Resources directory of the 
> application when the 'install' target is used ('pbxbuild install' from 
> the command line).
>
>     - the main.m uses execve() to transfer control to /usr/bin/python 
> and exec Main.py in a fashion where OS X thinks that /usr/bin/python 
> is the executable within the app wrapper (otherwise, mainBundle 
> breaks).  Unfortunately, this is what breaks gdb.  Fortunately, this 
> will go away when Apple ships a new build of Python that includes a 
> library for embedding.
In a conversation about an 'addon-for-Apple-python' version of 
MacPython I mentioned this technique to Jack Jansen (the MacPython 
maintainer). He intends to use a slightly different technique: The 
wrapper does not use execve() /usr/bin/python, but a python binary(*) 
in the Contents/MacOS directory of the .app with and argv[0] that 
actually points to this python binary. The reason for this variation is 
that this would make 'sys.executable' point to a python interpreter and 
appearantly some existing code expects this (including the Python 
testsuite). We didn't know if the APIs that require a full path to the 
application in argv[0] would mind that argv[0] is not the name of the 
binary mentioned in the Info.plist.

Ronald

(*) Actually a symbolic link, but that is not important for the rest of 
this message.