[Pythonmac-SIG] MacOS X Server, round 2 (long-ish)

Jeffrey P Shell jeffrey@Digicool.com
Mon, 03 May 1999 12:59:16 -0400


First a quick question: is this an appropriate place to talk about Python 
on MacOS X Server ?

I got Python 1.5.2 working with threads and managed (finally) to get Zope
running with ZServer.  There was some minor trickery involved and I'm not
sure if how "right" i did everything.  I saw a message from someone who
works in the MacOS X Server tools group who said they had 1.5.2b2 building
succesfully and want to know what they did.

To get it working with so that Zope (which seems to prefer having shared
libraries, which i prefer anyways) would work, i configured it with the
following:

./configure --with-threads --with-dyld --with-next-framework
--prefix=/usr/local/python152

An initial problem with this was that make install and friends would
install, naturally, in to (prefix)/lib/python1.5

However, enabling --with-next-framework works under the assumption (which
is probably logical) that Python is going into a .framework directory,
which takes care of versioning on its own, and creates the default sys.path
to be like "['.../lib', '.../lib/lib-dynload']", etc, instead of
lib/python1.5, lib/python1.5/lib-dynload, etcetera.

Not knowing enough about OpenStep's .framework setup, I wanted everything
to go into /usr/local/python152 like normal.  So I modified the C code that
doesn't add the python1.5/ to the path when being built for NeXT
frameworks.  I don't know how right this was.  But, this did work for my
purposes.

Furthermore, when configured --with-next-framework, it seems most (or all)
of the executable code is actually put into "libpython1.5.dylib", which
didn't seem to get picked up by "make install".  If i put a copy of
libpython1.5.dylib into /usr/lib, running Python works fine.  But it had to
be done manually.  Again, I don't know if this was the right thing to do.

Now what happened from this is that the C code to figure out the path/name
of the Python executable (in sys.executable) points to
"/usr/lib/libpython1.5.dylib".  Zope builder scripts use sys.executable for
a couple of purposes, expecting a value that's the path to the executable
(ie, "/usr/local/bin/python1.5").  I manually changed the Zope scripts to
use the real python instead of using sys.executable, but this would only
work on my machine.

I think running configure with no options set created a static python just
fine.  I've had problems running it with just the --with-dyld option set.
But Zope wanted to work with .so files, and compiling with
--with-next-framework seems to be the only way to get that working
properly.  (Another issue with this is, the Makefile.pre.in that gets
installed in lib/python1.5/config/ doesn't save the LDLIBRARY which the
--with-next-framework needs, and therefor compiling Zope couldn't link
properly until I added the following line in the Makefile.pre.in::)

LDLIBRARY=/usr/lib/libpython($VERSION).dylib

I think building/installing into a Framework is what I need to do, but I
don't want to trip over or cause any problems with Objective Everything's
Python installation (which is in
/Local/Library/Frameworks/Python.framework).  When I get back into MacOS X
Server (my Bluebox doesn't seem to work, i don't know if it's memory issues
or something else, so right now I'm dual booting with MacOS 8.5.1)

FWIW: Objective Everything will work with Carbon!  Another way of working
with Mac applications with Python. :)  I haven't played with Objective
Everything too much, but what I did see was pretty cool.  I wonder if its
would have a hard time with Python 1.5.x though.. :/ (like someone
mentioned earlier, the shipping version uses 1.4).

.jPS | jeffrey@digicool.com
zope, through the web. www.zope.org