[Pythonmac-SIG] Python Framework

William Noon noon@snow.cit.cornell.edu
Fri, 17 Aug 2001 13:46:30 -0400


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.  

After this, the sys.executable is still pointing to 
/Library/Frameworks/Python.framework/Versions/2.2/Python which is the
library.

Appended are a couple of patches to getpath.c and Makefile.pre.in that 
fix this and make a couple of other changes.  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 insensitive
problems in the build directory anyway.

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

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

--Bill Noon
Cornell University

# cvs diff -u Modules/getpath.c Makefile.pre.in
Index: Modules/getpath.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/getpath.c,v
retrieving revision 1.38
diff -u -r1.38 getpath.c
--- Modules/getpath.c   2001/08/15 01:14:40     1.38
+++ Modules/getpath.c   2001/08/17 17:06:09
@@ -392,8 +392,16 @@
                strncpy(progpath, prog, MAXPATHLEN);
         }
         else {
-               /* Use the location of the library as the progpath */
-               strncpy(progpath, buf, MAXPATHLEN);
+               /* Use the location of the library as the base for progpath.
+                ** This has to be adjusted for commandline python
+                ** and assumes that the program is called 'python'
+                ** When the python.app wrapper is built, adjustments
+                ** will have to be made.
+                */
+                strncpy(progpath, buf, MAXPATHLEN);
+                reduce(progpath);
+                joinpath(progpath,"bin");
+                joinpath(progpath,"python");
         }
     }
     else {
Index: Makefile.pre.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/Makefile.pre.in,v
retrieving revision 1.51
diff -u -r1.51 Makefile.pre.in
--- Makefile.pre.in     2001/08/15 01:26:28     1.51
+++ Makefile.pre.in     2001/08/17 17:06:09
@@ -781,6 +781,12 @@
        $(LN) -fs Versions/Current/Headers $(PYTHONFRAMEWORKINSTALLDIR)/Headers
        $(LN) -fs Versions/Current/Resources $(PYTHONFRAMEWORKINSTALLDIR)/Resources
        $(INSTALL_DATA) $(LDLIBRARY) $(PYTHONFRAMEWORKPREFIX)/$(LDLIBRARY)
+       -if test -f $(BINDIR)/python; \
+       then rm -f $(BINDIR)/python; \
+       else true; \
+       fi
+       (cd $(BINDIR); $(LN) python$(VERSION)$(EXE) python)
+       (cd /usr/local/bin; $(LN) -fs python$(VERSION) $(BINDIR)/python)
 
 # Build the toplevel Makefile
 Makefile.pre: Makefile.pre.in config.status

> 
> Recently, William Noon <noon@snow.cit.cornell.edu> said:
> > When installing, it only copied over the Versions tree and didn't make
> > the symbolic links for Headers, Resources and Python.  It also didn't 
> > create the bin, lib, include and man directories.  I brought these
> > over by hand and made the appropriate links.
> 
> Did you use "make frameworkinstall"? It should first do "make install"
> to put a standard Python installation (bin, lib, etc) into
> /Library/Frameworks/Python.framework/Versions/2.2 and then a "make
> frameworkinfrastructureinstall" which creates the symlink jungle.
> 
> > I need to use the command
> > line version so I made a link from
> > /Library/Frameworks/Version/Current/bin/python.exe -> /usr/local/bin/python
> > Even once the Python.app is set, I think we will need a python in
> > the std bsd PATH somewhere.
> 
> Yes, we definitely need this too. But: at this point we don't know
> where the user would like it, as we've overridden $(prefix) to point
> to the location where we want it.
> 
> One thing we could do is add an extra target ("make cmdlineinstall"?)
> and stuff the symlinks into /usr/local. Does anyone have better ideas?
> 
> > It looks like some more magic is needed in Modules/getpath.c to 
> > get the sys.path and sys.prefix and sys.executable to point to the
> > right place.  sys.path includes the build directories but not the
> > real libs.
> 
> This is funny. It may be another symptom of the next problem, or it
> may be that your framework installation isn't complete. getpath.c
> looks at <frameworkbase>/Lib/python2.2/os.py, and if it doesn't exist
> it assumes it is running with the "skeleton framework" which is
> created in the build directory. So either it really is doing that
> (see below) or your /Library/yaddayadda installation is incomplete.
> 
> > sys.executable/sys.prefix will try to execute the 
> > Python library at Versions/2.2/Python.  This specifically shows up when
> > building the mxBase stuff.  Other, simple modules (like bsddb3) work fine.
> 
> Are you sure sys.prefix is pointing to the local copy too? I always
> see sys.prefix as /Library/tralala, even when running with the local
> copy of the framework and sys.path pointing to the build directories.
> 
> There is some magic here, though. Tony came up with the elegant solution of
> referring to the framework not by its full /Library/tadidadida path
> but by a relative path starting with
> Python.framework/Versions/2.2. Due to the dyld search code this works
> great in 2 situations:
> 1) You're running from the build directory, Python hasn't been
> installed yet and you're trying to run, say, setup.py.
> 2) Python has been installed, and you're not in the build directory.
> 
> You now have a third case:
> 3) You're in the build directory, but Python has been installed and
> you would like to use that version. However, dyld prefers the
> Python.framework in the local directory over that in the
> /Library/Frameworks directory.
> 
> I'm not sure I understand how sys.prefix can be wrong. And I assume
> that that's the only one that really matters, or not? Could you pleaee
> investigate a bit more?
> --
> 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