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: The MacPython project files are configured to include a plethora of optional modules, and these modules need a number of extra packages. To use the project files as-is you have to download these packages too. PPC and CFM68K Python have 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 static 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), and edit the Mac:mwerks:mwerks_nonshared_config.h file to remove the USE_... line. Here are the locations for the various things you need:

Setting Up

Now that you have collected everything you should start with building the various parts. If you don't want to fix access paths try to set things up as follows: 
Top-level-folder:
	CWGUSI
	imglibs
		libjpeg
		pbmplus
		libtiff
		zlib
		libpng
	gdbm
	Python
	Tcl/Tk Folder
		tcl8.0
		tk8.0
		MoreFiles 1.4.3
	Waste 1.3 distribution (if you want waste)
First build GUSI. If you didn't get the python-specific GUSI you have to move the files from the "CWGUSI-mods" to the right place in the CWGUSI distribution folder. Build the MSL version for your platform (ppc, 68k, cfm68k).

Next, in MoreFiles, libjpeg, pbmplus, zlib, libpng, gdbm, andlibtiff you build all projects. Usually the projects are in "mac" subfolders, sometimes they are in the main folder. Tcl/tk is a special case, see below. Of course, if you are only interested in one of static 68K, CFM68K or PPC you can skip building the other libraries.

Building Tcl/Tk

You need to make some minor changes to the Tcl/Tk 8.0 distribution. You should make the CW Pro projects (in the mac subfolders). Build first 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.

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.macstand
This is where you build static 68K interpreter, and possibly (if you want them) static PPC and fat interpreters. There is also a project here that builds smaller versions of the static interpreter.
build.mac
This is where you build the CFM68K, PPC and fat shared library, interpreter and applet framework. The fat targets are deposited in the main folder (one level up), the others, which are intermediate results really, are left here.
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 always built here, as they are on Unix, but sometimes 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 and CFM68K 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.macstand and build the 68K target. Do not run it yet, this will possibly result in a garbled preferences file.

First remove the Python XXX 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 ReadMe in the Mac folder.

Building the PPC and CFM68K interpreter

First you build the interpreter, core library and applet skeleton in folder build.mac. The projects are all linked together, so building the fat targets in Python.prj and PythonApplet.prj will result in everything being built. The resulting applications and fat shared library are deposited in the main Python folder. For completeness sake here is a breakdown of the projects:
PythonCore (with subprojects PythonCorePPC and PythonCoreCFM68K)
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 if you rebuild the library and forget to copy it to the extensions folder again.
Python
The interpreter. This is basically a routine to call out to the shared library.

PythonAppletPPC
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 remove any old Python XXX 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.

Next, you have to build the extension modules in the PlugIns folder. The PlugIns.ppc project has all the other projects as subprojects and builds everything. 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. Run the ConfigurePython.py script from Mac:scripts to create the aliases.

Finally, you must build the standard applets: EditPythonPrefs, BuildApplet, etc. This is easiest done with the fullbuild script from Mac:scripts.

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 ReadMe file from the Mac folder.

Rebuilding .exp files for PPC and CFM68K

Occasionally it may be necessary to rebuild your PythonCore .exp file, a file that controls which symbols are exported by your PythonCore shared library. Rebuild it if you get unexpected undefined symbols when you are building a plugin module.

Rebuilding the .exp file is done by first removing the file and removing the reference to it in the project (in the "config" section). Next, build PythonCore. This will create a new .exp file. Edit this file to remove the references to the symbols __initialize, __terminate, setjmp, longjmp, main and (for PPC) __ptmf_null or (for CFM68K) __start and dummy_init_routine. Next, add the .exp file to the project again and rebuild PythonCore.

This rather convoluted procedure is needed to ensure that plugin modules don't accidentally link with those entrypoints from PythonCore, which will not work because those routines have to be in the same code fragment as they are used from.

Odds and ends

Some remarks that I could not fit in elsewhere: