Re: [Pyobjc-dev] buildapplication strawman

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

On Monday, Nov 18, 2002, at 00:46 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> Mac/script/buildappbundle.py
>
> Ok, I've had a closer look at it: great! Mind if I take a hack at it? 
> I would
> like to move it to Mac/Lib/ though. It it used much? Would people 
> likely get
> upset if I change the (function) interface?

It's only been there for a week or two, so I doubt anyone gets upset. 
But: do keep the commandline
interface working (or, if you move the functionality to Lib, keep the 
driver main program in the
scripts folder), as I use it when building MacPython-OSX 2.2 (the 
MacPython that will sit on /usr/bin/python).

And note that the tool has nothing python-specific, really. I use it 
with my OpenGL C and C++ applications too.
I build these with Makefiles (they run on both Linux and OSX), and for 
OSX the last build step is buildappbundle,
which stuffs the executable into a .app bundle (on Linux this step is 
skipped).

> - I would not let people specify a nib by path, but by name, 
> defaulting to
>   "MainMenu". The .lproj or individual nibs should then be listed as a
>   resource.

Why? If there is a good reason to disallow full pathnames: fine with 
me, but I don't
immediately see why this would be so.

> - I don't care much for the command line interface: I think people 
> should just
>   write a setup.py-like script. I wouldn't rip main() out, but I 
> wouldn't want
>   to spend much time on it.

As said above: I need it for building Python.app for 2.2 MacPython-OSX.

> - I think it's good if it (by default) would build the app in a build/ 
> subdir,
>   like distutils and PB.

I've been working to the analogy of BuildApplet, but I'm not 
particularly married to that.

>
> Further things I'd like to do:
>
> - Change it to use the os.execve() trick.

Definitely, but as an option. The only thing I'm not sure about is 
whether the execve code
should be in-line in a string (as in your version) or external on 
sys.path (as buildtools.py
currently does).

> - I would like to add a debug or "developer" option: instead of 
> copying the
>   files/folders it would put symlinks inside the bundle. That way it's 
> easy
>   to keep on hacking on any file without having to rebuild the app all 
> the time.

Yes, good idea.

> - Add modulefinder support, like we discussed by telepathy... The full 
> version
>   would also copy the Python executable to Contents/Resources/. Not 
> sure what
>   to do about a Framework python, though. Not sure I even care about 
> that
>   anymore: it only seems to make thing harder here. What do you think?

I think the framework python is still my preferred option, and I hope 
we can get Apple to adopt it at some point in the future. but for the 
time being I want to keep both working.

As to modulefinder support: I think we need to think architecture 
first. We now have a number of modules and scripts that do things that 
are vaguely similar conceptually, but very different in implementation:
- buildtools can build MacPython-OS9 applets.
- buildtools can build MacPython-OSX applets.
- buildtools can help with building MacPython-OS9 applications.
- BuildApplication uses buildtools and selected bits of freeze to build 
applications for MacPython-OS9.
- buildappbundle can build general .app bundles.
- your tool can build .app bundles specific for Python applets.

How about structuring this whole lot as a package? We could then make 
sure that the OS9-specific code (which would depend on MacPython 
functionality for resource-file mangling, for instance) would be in a 
separate module so it wouldn't be seen when building a PyObjC applet 
with /usr/bin/python. Also, there's heaps of data that the modules 
above rely on, and currently some of it is hardcoded in strings (your 
execve code, the plist data in your script), some of it is in modules 
on sys.path (__rawmain__ aka appletrawmain, appletrunner), some of it 
is somewhere completely different (Applet-Info.plist). If we have a 
package we also have a neat place to store all this data, in separate 
files.
>
> - A strip binaries option. Hm, evil? Could save a huge amount of disk 
> space,
>   though.

Good idea. But: is "strip" available if you don't have the dev tools 
installed?
>
> Question: is it possible to completely override sys.path for a 
> statically built
> Unix Python? $PYTHONPATH merely prepends sys.path. Would be nice to 
> completely
> control it for a standalone app bundle.

You could create lib/python2.2 and lib/python2.2/lib-dynload under 
Resources, and then set
PYTHONHOME to Resources.

Hmm, this could be an interesting way to distinguish applets and fully 
self-contained applications:
if there is a lib/python2.2 and lib/python2.2/lib-dynload then we set 
PYTHONHOME. We could then copy
/usr/bin/python to the MacOS directory too, and use that to run the 
standalone application.

For static python this is good enough. For framework python more magic 
is needed.
--
- 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 -