Re: [Pyobjc-dev] Achieving 1.0....
Brought to you by:
ronaldoussoren
From: Bill B. <bb...@co...> - 2002-10-22 21:23:23
|
On Tuesday, October 22, 2002, at 05:03 PM, Ronald Oussoren wrote: > On Tuesday, Oct 22, 2002, at 22:47 Europe/Amsterdam, Bill Bumgarner > wrote: > ..... >> >> I'm pretty happy with the latest incarnation of bin-python-main.m -- >> need to commit a new version and update the python project template >> -- as it has proven to not be problematic in the production app I'm >> working on. It now supports standalone builds with frameworks >> (dynamically loading frameworks with @executable_path as their >> install_name AND dependencies on other frameworks w/@executable_path >> requires some fun to be had with the environment variables of the >> execve() process). > I'll also have a more serious look bin-python-main.m. I definitely > like the idea of just exec-ing a normal python with the right argv. > > The only thing I'm not sure about w.r.t. binary distribution of > applications is honouring a 'defaults' settings for the location of > the python binary. But that is something we can fix in our in-house > version of python (we ship extension modules, and those might not work > with a different version of python). It already does that and much, much more! :-) See both the main-bin-python.m and the Main.py in the Web Services Tool example. It is the "most correct" version I have created so far and will be copied to the other projects / locations soon. Some of the nifty features: - auto dumps the pid for attaching to the child python process via gdb if SHOWPID is set in the environment - correctly sets up environment variables to deal w/linking frameworks in production vs. in project builder - traverses list of frameworks linked into the main-bin-python.m binary and passes 'em off to the Main.py. Main.py dynamically loads each framework, then checks each framework to see if it has an Init.py script in Resources/ and executes it, if it does. I.e. frameworks will auto-bootstrap their python stuff as they are loaded into the "real" environment. - can customize which python binary is used via the PythonBinPath user default - can customize the Main script used via the main bundles PrincipalPythonFile dictionary entry; defaults to Main.py (should add this to the project template, now that I think about it). - everything is done w/UTF-8 encoded strings and, as such, should work on any OS X installation [as the BSD layer all deals w/UTF-8 encoded strings for paths and such]. - setting the DYLD_PRINT_LIBRARIES user default to 1 will cause the child python process to dump all of the dylibs as they are loaded >> I'll try to re-address the documentation on the examples that use >> Project Builder and put together a README for the Project Template >> stuff. > Documentation, the mortal enemy of coders :-) I like using unit tests as documentation, personally. We [CodeFab] have been using XP in varying levels of intensity over the past few years. When it works, it works really well. b.bum |