Re: [Pyobjc-dev] buildapp.py and bootstrapping

[Bob I. <bo...@re...>]

On Wednesday, Oct 15, 2003, at 13:25 America/New_York, b.bum wrote:

> Any chance of upgrading buildapp.py with one (or both) of two features  
> that would make debugging via gdb a boatload easier?
> - add ability to copy in a bootstrap executable that uses an embedded  
> Python interpreter in place of the script/link that exist today

I don't see why this would be hard to do, and I think it makes sense  
and it brings back potential OS X 10.1 compatibility as well, right?   
Not that I care, but someone might.
Realistically though, couldn't you just write a script to launch gdb  
with the right args, like this (imagine a simple shell script to  
automate this):
	gdb --args  
/Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/ 
Contents/MacOS/Python `pwd`/build/DrawBot.app/Contents/MacOS/DrawBot

This is *nix, remember?  ;)

> - build a bootstrap executable ala distutils that allows the developer  
> to link in other frameworks and/or their own compiled code as a part  
> of the buildapp.py process?   This would both address the gdb issue  
> and allow the developer to trivially interleave ObjC or other compiled  
> code without using one of the project templates/PBX.

I've never had a problem using GDB with dynamically loaded code (via  
ObjC frameworks or Python extension bundles), so why do you need/want  
this?	- It's easier (from the Python side) to just compile the ObjC  
code as frameworks and load it in dynamically, would the ObjC runtime  
even find your compiled code otherwise?
	- "other compiled code" wouldn't be useful from Python without a  
python module to support it.. IIRC, the code is almost the same whether  
you make it a bundle or extend an embedded interpreter, why not just  
make it a module?