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

[Jack J. <Jac...@or...>]

On vrijdag, november 1, 2002, at 03:55 , bb...@ma... wrote:

> On Friday, November 1, 2002, at 07:05 AM, Jack Jansen wrote:
>>>       - 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).
>> Please have a look at BuildApplication (and the underlying 
>> freeze modules), so you don't go reinventing the wheel. 
>> BuildApplication first recursively collects all modules used 
>> by a script, then byte-compiles these and then stuffs them 
>> into OS9 resources. The last step needs to be modified for 
>> OSX, but the first step (which is basically shared with 
>> freeze) can definitely be used.
>
> I think we are talking about two different ways of building 
> applications.

Yes, after reading Ronald's original message again I think I did 
misunderstand it. I thought the discussion was about including 
and precompiling all the stuff you need (including standard 
modules, stuff from site-python, etc), but it was only about 
precompiling the "private" stuff. Sorry.

>> On vrijdag, nov 1, 2002, at 03:53 Europe/Amsterdam, 
>> bb...@ma... wrote:
>>> On Thursday, October 31, 2002, at 04:42 PM, Ronald Oussoren wrote:
>>>> On Thursday, Oct 31, 2002, at 14:20 Europe/Amsterdam, 
>>>> bb...@ma... wrote:
>>>>> .....
>> I think there's a misunderstanding somewhere in the 
>> me->ronald->bill conversation, as I don't see why Bill's 
>> method would be different from mine. In other words, please 
>> explain if there is...
>>
>> Here's my scheme, with an example:
>> /Applications/foo.app/Contents/MacOS/foo looks for __main__.py 
>> in Resources, and does 
>> execve("/Applications/foo.app/Contents/MacOS/python",
>> 		["/Applications/foo.app/Contents/MacOS/python",
>>      	 "/Applications/foo.app/Contents/Resources/__main__.py",
>> 	 	 rest of original argv])
>> and Contents/MacOS/python is a symlink to /usr/bin/python.
>
> In terms of passing control to the python interpreter, the two 
> solutions are doing same thing excepting for the symlink and 
> the direct insertion of the python binary into the app wrapper.

As Ronald already explained there's only a symlink.
>
> The key difference is in the information contained within the 
> executable found within the app wrapper.  In my solution, the 
> executable automatically carries the information about what 
> frameworks are used into the python interpreter by simply 
> linking the custom executable against the appropriate 
> frameworks.

This bit I don't understand. First of all, if you are able to 
"carry information about what frameworks are used into the 
python interpreter": why would that only work if you exec() 
/usr/bin/python, and not when you exec() 
..../Contents/MacOS/python which is a symlink to 
/usr/bin/python? Second, I don't understand how you carry this 
information over. Once you exec() the running binary is blown 
out of the air, and anything it is linked against disappears. 
And if the carrying-over somehow happens through open files, or 
argv[0] or some such it will work just as well in "my" scheme....

[...]
>     (2) Make it such that the second invocation of 
> sys.executable [which points to the bootstrap binary in my app 
> wrapper] simply calls execve() with a command line that passes 
> control to python along with the arguments.

Now you have me completely confused. How would the wrapper know 
it is invoked for a second time? And how would this be different 
from a completely unrelated call to the applet?
> --
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -