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

[Peter M. <zig...@po...>]

On Saturday, November 9, 2002, at 04:56 AM, bb...@ma... wrote:

> The setenv() call would have to happen in the main [python] 
> executable.  The PyObjC module is too late because it is dynamically 
> loaded.    Back to square one-- we could use a Python script in the 
> app wrapper, but it would (a) be slower and (b) not add any 
> functionality over the current bootstrap executable.
>
> BTW:  There is nothing app specific about the bootstrap executable.  
> You don't even need to compile it to use it in another project-- just 
> add a copy files phase that copies the executable into the Executables 
> area of the app wrapper and make sure that the executable name 
> attribute in the info dictionary of the app wrapper is set correctly.

Yeah, the first thing I tried was a python script as the executable 
that mirrors bin-python-main.m ie. it calls the python version of 
exec(). It works without any problems but as you said, there isn't any 
point.


>> I think I know what will help me: a proper build of python. So what 
>> is recommended? CVS python? Stable python? Fink?
>
> Fink rocks.
>
> I would go with Fink -- make sure you follow the 10.2 instructions at 
> fink.sourceforge.net.   It keeps itself up to date quite nicely and is 
> incredibly easy to uninstall (fink remove python -- once it is built, 
> there will be a debian package containing the python build and, 
> therefore, a subsequent fink remove / fink install of python does not 
> require it to be rebuilt).   Go with 'python-nox' if you don't have or 
> want X11 installed.

I haven't got fink for 10.2 yet. How different is it from stable python?


>> Unfortunately, I can't read binary :-)
>
> A trick:
>
>     otool -TtVv /usr/lib/crt1.o

Ah, thanks. I was doing otool -tv /usr/lib/crt1.o. The other options 
make it much more readable. Still can't really figure it out but I can 
see where it sets _NXArgv.


>> I'm a very curious person. But one can only be so curious when one is 
>> trying to read messy, #ifdef laced source code through a CVSWeb site 
>> over a dialup link.
>
> Agreed.  C in this form is very much like macro assembly....

Sums it up well.


>>> In any case, all of this-- the whole execve() style bootstrapper-- 
>>> is just a hack that'll go away as soon as we have an embeddable 
>>> build of Python shipping with OS X.
>>
>> Yeah, I know. I just had the kluge alert going off in my head and I 
>> felt compelled to try and fix it. Anything other than the current 
>> hack is going to be an even bigger hack. You guys have done a great 
>> job.
>
> Thanks.  It just got better.  If you cvs update the pyobjc source 
> tree, the new Cocoa-Python project template has been cleaned up a bit. 
>   BTW:  You can create a symlink from /Developer/ProjectBuilder 
> Extras/Project Templates/... wherever ... to the project template(s) 
> in the pyobjc source tree directly.   Just make sure you don't end up 
> w/a .pbxuser file in the template pbproj....

Done.  Main.py is now __main__.py? Good idea. My only problem with the 
current scheme is that you have to add import statements for your 
source. Is there away this could be automatically, or better yet 
dynamically? It would be nice if the user didn't have to touch 
__main__.py manually. It would be even nicer if __main__.py could 
figure out where the other stuff is itself.

Peter