Re: [Pyobjc-dev] Python rather than ObjC for main?

[<bb...@ma...>]

On Wednesday, November 6, 2002, at 09:23 AM, Peter Montagner wrote:
> Is there any reason why the executable pointed to by 
> CFBundleExecutable has to be a Mach-O file?

Not in and of itself... but it fixes a separate problem with the 
lightest possible solution I could come up with (faster than launching 
Python interpreter).

> Now, I've been experimenting with making a modified Main.py the 
> CFBundleExecutable, hoping to avoid the execve(). I can't seem to get 
> it working though. NSApplicationMain() dies complaining about not 
> finding the Info.plist file. I'm not sure I understand what's 
> happening. The launch arguments seem to carry across OK.
>
> Am I reinventing the broken wheel here? Do we have the execve() 
> procedure because the simpler approach fails?
>
> Obviously this approach would be inferior to having an embeddable 
> version of python in an ObjC wrapper but could this approach be used 
> to remove the execve()?

Whatever actually executes the application-- be it a direct executable 
or the python interpreter-- must be physically located within the app 
wrapper (can be a symlink).  As Ronald noted, NSBundle's mainBundle 
doesn't initialize correctly otherwise.

For example, say I have the following script as /tmp/b.py:

#!/usr/bin/env python
from Foundation import *
print NSBundle.mainBundle().bundlePath()

Then:

[bumbox:~] bbum% python /tmp/b.py
/usr/bin
[bumbox:~] bbum% /tmp/b.py
/usr/bin

The problem is that NSBundle determines the directory of the main 
bundle based on argv[0] -- not sys.argv, but the argument list passed 
into the python interpreter itself (which removes itself from argv 
before passing control to the script).

The execve() based main() simply constructs a set of arguments that 
points to the script inside the app wrapper as argv[0] before passing 
control to the python interpreter.   This way, NSBundle initializes 
correctly after control is passed to the python interpreter.

(This really isn't a bug in NSBundle -- more of a lacking feature.  
There needs to be a way to tell NSBundle that yes, in fact, you really 
want to point the main bundle HERE and not THERE before it initializes. 
  An enhancement request has been filed at bugreport.apple.com.)

A symlink to the python interpreter could be included in the app 
wrapper, but that would be extremely fragile for all but the Apple 
provided interpreter.   The call to execve() doesn't add *that* much 
overhead to the startup process and the current main() and Main.py can 
do things like automatically loading frameworks based on what is linked 
into the executable (as well as a handful of other features).

I'm going to clean up everything, including the project template, in 
preparation for a 0.8.0 release.   Take what we have now and release it 
so people don't stumble on 0.6.x any longer...   Want to have it out by 
end of this weekend.

b.bum