[Pythonmac-SIG] Python Framework

[Jack Jansen]

Recently, William Noon <noon@snow.cit.cornell.edu> said:
> Jack -- I didn't do a 'make frameworkinstall'.  After zapping the 
> /Library/Frameworks/Python.... tree and making appropriately, all the
> symbolic links were there.  When the dust settles, if the user selected
> --with-framework, the 'install' target should do the 'frameworkinstall'
> stuff since it is halfway there already.  

Are you really sure? I just zapped everything, rebuilt, and did a
"make install" (not a frameworkinstall) and for me no symlinks were
created, just a "normal" Python installation in
/Library/Frameworks/Python.framework/Versions/2.2/ .

Could this be an effect of your Makefile.pre.in mods?

> Appended are a couple of patches to getpath.c and Makefile.pre.in that 
> fix this and make a couple of other changes.

I want to have a look into this, or maybe someone in the know can
provide some clues. The original NeXT code explicitly set progpath to
point to the shared lib. It could be that that is because the code
predates sys.executable but I'd have to check.

> Since the framework is already
> versioned, the Makefile will create a hardlink from python2.2.exe to python
> in the ...Versions/2.2/bin directory.  getpath.c doesn't know about
> $(EXE).  The .exe extension was only needed to get around the case insensitiv
> e
> problems in the build directory anyway.

What I'd like is to use the silly extension only in the build directory. That
would require a $(BEXE) that is set to ".exe" on OSX (automatically,
without the --with-ext option) and to $(EXE) on other machines. But it
needs a bit of looking into to see which $(EXT) would have to be
replaced by $(BEXT).

If anyone feel likes doing the work just put a patch into the
sourceforge patchmgr and assign it to me.

> When an .app wrapper is done, we will need to distinguish between these two
> binaries.

I did a quick scan for sys.executable in the Python tree, and except
for the references that were (a) wrong or (b) not applicable all but
one reference used it to build something to pass to os.system(). So in
the .app case we should either have it point to the application within
the .app bundle (if that accepts command line args) or to the one in
the framework bundle (as your fix does).

> I also make a link from the binary to /usr/local/bin/python$(VERSION) so
> it will show up in the path.

Your the Nth person suggesting this, and I'm somehow a bit reluctant
to hard-code a /usr/local/bin path into the Makefile. For one, the
current config process allows you to use "configure
--enable-framework=/Users/jack/Frameworks" if you don't have admin
privileges and everything will work fine.

But I also don't know another solution. Folks: can you please come up
with ideas, or tap me on the shoulder and say "Nah, Jack, don't worry,
put the hard pathnames in and we'll defend you if the Big Bad BDFL
comes raining fire and brimstone on you"?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm