Building Mac Python from source
This document explains how to build MacPython from source. This is
necessary if you want to write extension modules for 68K Python, and
currently also probably the easiest way to build PPC extension
modules. Building Python is not something to be undertaken lightly,
the process is not very streamlined so you need a reasonable working
knowledge of the CodeWarrior development environment, a good net
connection and probably quite some time too.
The information density in this file is high, so you should probably
print it and read it at your leasure. Most things are explained only
once (and probably in the wrong place:-).
I am very interested in feedback on this document, contact me at <jack@cwi.nl> or send your
comments to the Mac Python Special
Interest Group.
What you need.
The following things you definitely need:
- You need a MacPython source distribution, of course. You can
obtain one from ftp://ftp.cwi.nl/pub/jack/python/mac,
and possibly also from the standard python.org ftp
site. Everything you need is also included in the standard Python
source distribution, but the organization is different. Look in
directory
Mac/mwerks/projects
for the project files and
related stuff.
- You need MetroWerks CodeWarrior. The current distribution has
been built with version 9 of CodeWarrior. Ordering information is
available on the MetroWerks
homepage. You might still be able to build Python with MPW or
Think/Symantec C but you are basically on your own.
- You need GUSI, the Grand Unified Socket Interface, by Matthias
Neeracher. The current distribution has been built with CWGUSI 1.7.2,
obtainable from ftp://ftp.switch.ch/software/mac/src/mw_c.
It is possible to build a non-GUSI Python, see below.
The MacPython project files are configured to
include a plethora of optional modules, and these modules need a
number extra packages. To use the project files as-is you have to
download these packages too. PPC Python has all such modules as
dynamically loaded modules, so if you don't need a certain package it
suffices to just refrain from builing the extension module. For 68K
Python things are a bit more complicated: you have to edit the
interpreter project file to remove the reference to the module (and
the libraries it uses). Here are the locations for the various things
you need:
- Tcl and Tk can be obtained from ftp://ftp.smli.com/pub/tcl/mac/.
The current distributions, Tcl 7.5p1 and Tk 4.1p1 need a bit of work,
see the section on building Tcl/Tk Python
below. Get the "full source" distribution, which includes MoreFiles.
- Waste, a TextEdit replacement written by Marco Piovanelli, <piovanel@kagi.com>. Python
was built using version 1.2, which you can obtain from <ftp://rhino.harvard.edu/pub/dan/WASTE>
and various other places.
- JPEG library by the Independent JPEG Group. Python is still built
using an archaic version of the library, version 4. It can be obtained
from the
ftp://ftp.cwi.nl/pub/jack/python/mac directory, complete with CW8
projects. If someone manages to build Python with the version 6
library I would be grateful if they sent me the changes needed. The
most recent JPEG library can always be obtained from ftp://ftp.uu.net/graphics/jpeg/.
- The netpbm/pbmplus and libtiff libraries. The netpbm distribution
(which includes libtiff) is generally available on Internet ftp
servers. For Python pbmplus, an older incarnation of netpbm, is
functionally identical to netpbm, since Python only uses the library
and not the complete applications. A distribution with correct
projects and library source only is available from, you guessed it, ftp://ftp.cwi.nl/pub/jack/python/mac.
Setting Up
Now that you have collected everything you should start with building
the various parts. Everything is independent, with the single
exception that Tcl and Tk depend on CWGUSI. If you don't want to fix
access paths try to set things up as follows:
Top-level-folder:
CWGUSI
imglibs
libjpeg
pbmplus
libtiff
MoreFiles 1.4.2 (not needed by Python, only by tcl/tk)
Python
Tcl 7.5
Tk 4.1
Waste 1.2 distribution (if you want waste)
Now build all the libraries. In CWGUSI
you build the
projects GUSI.68K.µ
and GUSI.PPC.µ
, in
MoreFiles
, libjpeg
, pbmplus
andlibtiff
you build all projects. Tcl/tk is a special
case, see below. Of course, if you are only interested in 68K you can
skip building the PPC libraries and vice versa.
You need to make a minor organizational change to the Tcl/Tk
distribution. The current instructions are for the
tcl7.5.1
and tk4.1.1
distribution:
- Rename the
compat
folders to (compat)
in both the Tcl and Tk folders.
- In the Tcl folder, move
strncasecmp.c
and
tclErrno.h
from (compat)
to the main Tcl
folder.
- Fix
dnr.c
as provided by MetroWerks by inserting
#pragma ANSI_strict off
at the
beginning. The tcl library is built with strict ANSI on, and this file
uses C++ style comments.
- If you want to build
SimpleTcl
and
SimpleTk
you will probably have to remove the references
to libmoto
from the project.
- You are strongly advised to add a line
#define USE_TCLALLOC 1
somewhere at the beginning of MW_TclHeader.pch
.
As distributed, tcl and tk assume that malloc calls always succeed and
use the resulting pointer without checking for NULL
values. Needless to say, this wreaks havoc on a Macintosh.
Build first the MoreFiles library, then the Tcl library, then
SimpleTcl (test it by typing ls -l
in the window you get)
then the Tk library, then SimpleTk (which can again be tested with
ls -l
). If this all worked you are all set to try
building Python.
Building Waste
You do not need to build the Waste libraries, as Python includes the
source modules themselves. You have to make one modification,
though. In file ICCFMGlue.c
in folder Minimal IC
APIs
, add the following lines:
#include
#include
The organization of the Python source tree
Time for a short break, while we have a look at the organization of
the Python source tree. At the top level, we find the following
folders:
- build.mac68k.stand
- This is where you will build 68K interpreters.
- build.macppc.shared
- This is where you build the PPC shared library, interpreter and
applet framework.
- build.macppc.stand
- This is where you build a nonshared PPC interpreter (optional).
- Demo
- Demo programs that are not Mac-specific. Some of these may not
work, the file
README-Mac
has some details.
- Extensions
- Extensions to the interpreter that are not Mac-specific. Contains
only the
img
extension in this distribution. Extensions
are not built here, as they are on Unix, but incorporated in
the core interpreter or built as plugin modules.
- Grammar
- The Python grammar. Included for reference only, you cannot build
the parser on a Mac.
- Include
- Machine-independent header files.
- Modules
- Machine-independent optional modules. Not all of these will work
on the Mac.
- Objects
- Machine-independent code for various objects. Most of these are
not really optional: the interpreter will not function without them.
- Parser
- The Python parser (machine-independent).
- PlugIns
- This is where you build the PPC dynamically-loaded plugin modules.
- Python
- The core interpreter. Most files are machine-independent, some
are unix-specific and not used on the Mac.
- Tools
- Tools for python developers. Contains
modulator
which builds skeleton C extension modules and bgen
which
generates complete interface modules from information in C header
files. There are some readme files, but more documentation is sorely
needed.
All the mac-specific stuff lives in the Mac
folder:
- Compat
- Unix-compatability routines. Some of these are not used anymore,
since CWGUSI provides a rather complete emulation, but you may need
these if you are trying to build a non-GUSI python.
- Demo
- Mac-specific demo programs, some of them annotated.
- Include
- Mac-specific but compiler-independent include files.
- Lib
- Mac-specific standard modules. The
toolbox
folder
contains modules specifically needed with various MacOS toolbox
interface modules.
- Modules
- Mac-specific builtin modules. Theoretically these are all
optional, but some are rather essential (like
macmodule
). A lot of these modules are generated with
bgen
, in which case the bgen input files are included so
you can attempt to regenerate them or extend them.
- MPW
- MPW-specific files. These have not been used or kept up-to-date
for a long time, so use at your own risk.
- mwerks
- Mwerks-specific sources and headers. Contains glue code for
Pythons shared-library architecture, a replacement for
malloc
and a directory with various projects for building
variations on the Python interpreter. The mwerks_*.h
files here are the option-setting files for the various interpreters
and such, comparable to the unix command-line -D
options
to the compiler. Each project uses the correct option file as its
"prefix file" in the "C/C++ language" settings. Disabling optional
modules (for the 68K interpreter), building non-GUSI interpreters and
various other things are accomplished by modifying these files (and
possibly changing the list of files included in the project window, of
course).
- Python
- Mac-specific parts of the core interpreter.
- Resources
- Resource files needed to build the interpreter.
- Scripts
- A collection of various mac-specific Python scripts. Some are
essential, some are useful but few are documented, so you will have to
use your imagination to work them out.
- Unsupported
- Modules that are not supported any longer but may still work with a little effort.
Building the 68K interpreter
If you have all the optional libraries mentioned above loaded buildin Python for 68K macs is a
breeze: open the project in the folder build.mac68k.stand
and build it. Do not run it yet, this will possibly result
in a garbled preferences file.
First remove the Python preferences
file from your
preference folder, only if you had an older version of Python
installed. (this is also what you do if you did not heed the last
sentence of the preceeding paragraph). Next, move the interpreter to
the main Python folder (up one level) and run it there. This will
create a correct initial preferences file. You are now all set, and
your tree should be completely compatible with a binary-only
distribution. Read the release notes
(Relnotes-somethingorother
) and
ReadMeOrSuffer
in the Mac
folder.
Building the PPC interpreter
First you build the interpreter, core library and applet skeleton in
folder build.macppc.stand
. The order to build things is
the following:
- PythonCoreRuntime
- A modified version of the MetroWerks runtime library that is
suitable for Pythons' shared library architecture. The sources all
come from the MW distribution.
- PythonCore
- The shared library that contains the bulk of the interpreter and
its resources. It is a good idea to immedeately put an alias to this
shared library in the
Extensions
folder of your system
folder. Do exactly that: put an alias there, copying or
moving the file will cause you grief later.
- PythonPPC
- The interpreter. This is basically a routine to call out to the
shared library. Because of the organization of GUSI it also contains
the Gusi settings resource (together with a ResEdit template, so you
can change the gusi settings should you feel like doing so). Do
not run it yet, this will possibly result in a garbled
preferences file.
- PythonApplet
- The applet skeleton application. Very similar to
PythonPPC
, but it calls to a different entrypoint in the
core library. The mkapplet
script will copy this complete
file, and add a 'PYC '
with the module to generate an
applet.
After creating the alias to PythonCore
you should move
PythonPPC
to the main Python folder. Next you remove any
old Python Preferences
file from the
Preferences
folder (if you had python installed on your
system before) and run the interpreter once to create the correct
preferences file. You should also make an alias to
PythonApplet
in the main Python folder. (again: making an
alias is preferrable to copying or moving the file, since this will
cause the correct file to be used if you ever rebuild
PythonApplet).
Next, you have to build the extension modules in the
PlugIns
folder. Open each project and build it. After all
the dynamically loaded modules are built you have to create a number
of aliases: some modules live together in a single dynamic
library. Copy or move the MkPluginAliases.py
script from
Mac:scripts
to the main python folder and run it.
Finally, you must build the standard applets:
EditPythonPrefs
, mkapplet
, etc. This is
easiest done with the fullbuild
script from
Mac:scripts
. Answer no to all questions except
when it asks whether to build the applets.
Actually, the fullbuild
script can be used to build
everything, but you need a fully-functional interpreter before you can
use it (and one that isn't rebuilt in the process: you cannot rebuild
a running program). You could copy the 68K interpreter to a different
place and use that to run fullbuild, or use the standalone PPC python
for this. I tend to keep a standalone interpreter in a safe place for
this use only.
You are all set now, and should read the release notes and
ReadMeOrSuffer
file from the Mac
folder.
Odds and ends
Some remarks that I could not fit in elsewhere:
- It may be possible to use the
PythonCore
shared
library to embed Python in another program, if your program can live
with using GUSI for I/O. Use PythonCore in stead of your C library
(or, at the very least, link it before the normal C library). Let me
know whether this works.
- It is possible to build PPC extension modules without building a
complete Python. Take the binary distribution, add folders
Include
, Mac:Include
and
Mac:mwerks
from the source distribution and you should be
all set. A template for a dynamic module can be found in
xxmodule.µ
.