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:-).
First a warning: this information may become outdated if a new CodeWarrior is released after MacPython. The MacPython homepage will hopefully have updated instructions in that case.I am very interested in feedback on this document, send your comments to the Mac Python Special Interest Group.
Top-level-folder: GUSI2 GUSI2Carbon imglibs jpeg netpbm libtiff zlib png gdbm Python Modules ... Mac Modules Build ... Tcl/Tk Folder tcl8.0 tk8.0 MoreFiles 1.4.3If your setup of the libraries is exactly the same as mine (which is not very likely, unless you happen to work from the same CVS repository) you can use the project
:Mac:Buildfolder to build all needed libraries in one fell swoop, otherwise you will have to build the libraries one by one.
First build GUSI, both the norla one and the Carbon variant.
libtiff 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.
Note that if you use a different release of Tcl and Tk than the ones
I have used you may have to adapt the Python
This is easiest done by building
SimpleTk and copying the TEXT, ICON
and CRSR resources from it to
tkresources.rsrc. This allows
_tkinter module to work without an installed Tk/Tcl on your
Also note that the
_tkinter.ppc.slb that is normally distributed
PlugIns folder is the one from the Imaging extension,
which has some extra features needed by PIL (and which features should not
hinder normal operation).
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
Numericalextensions in this distribution.
modulatorwhich builds skeleton C extension modules,
bgenwhich generates complete interface modules from information in C header files and
freezewhich is used to turn Python scripts into real applications (used by MacFreeze and BuildApplication) There are some readme files, but more documentation is sorely needed.
toolboxfolder contains modules specifically needed with various MacOS toolbox interface modules.
macosmodule). 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.
mallocand a directory with various projects for building variations on the Python interpreter. The
mwerks_*.hfiles here are the option-setting files for the various interpreters and such, comparable to the unix command-line
-Doptions 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).
First you optionally build the external libraries with buildlibs.prj. Next,
the projects for
interpreter and core library are linked together, so
building the PythonInterpreterClassic and/or PythonInterpreterCarbon target
will result in everything being built. The result, however, is an "Application
template", (filetype Atmp). If you don't use fullbuild you can manually
turn either of these into an interpreter by copying it to PythonInterpreter
and setting the filetype to APPL (with ResEdit or some such).
Fullbuild does this for you, and the Atmp files is also how ConfigurePythonCarbon and ConfigurePythonClassic work their magic.
For completeness sake here is a breakdown of the projects:
Extensionsfolder 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. The ConfigurePythonXXX applets will also do this.
PythonCoreyou remove any old
Python XXXX Preferencesfile from the
Preferencesfolder (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. If you don't use fullbuild simply open each project and build it.
Finally, you must build the standard applets:
BuildApplet, etc. For the N-th time:
fullbuild does this for you, but you can also manually drag/drop them onto
TheYou are all set now, and should read the release notes and
fullbuildscript 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 interpreter to a different place and use that to run fullbuild. The
PythonStandSmall.prjproject builds an interpreter that is suited to this, and it can also come in handy if you need to debug things (which is easier in a static program).
ReadMefile from the
.expfile, 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 both removing the file and removing the
reference to it in the project (in the "config" section). Next, build PythonCore or
This will create a new .exp file, with the name
Rename this file to either
and add this file back to the project. Next, edit ot to remove the references to
They are all close together about halfway the file.
Finally rebuild again.
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.
The CVS client of choice is Alexandre Parenteau's MacCVS. It can be obtained through the WinCVS homepage. MacCVS uses Internet Config to set file types correctly based on the filename extension. In the maccvs preferences you should also set (in the "binary files" section) "use mac encoding: applesingle" and (in the "text files" section) "use ISO latin 1 conversion".
There is one group of people for whom MacCVS is not the best choice: people with checkin rights to the Python repository. You will have to use MacCVS Pro (completely unrelated) from www.maccvs.org, because it has working SSH support.It is a good idea to disable Quicktime Exchange in the Quicktime control panel. Quicktime Exchange will magically map some extensions to filetypes, and this can seriously hinder you if, for instance,
.bmpis not a Windows bitmap file.
The Python sources are checked out from the main
Python CVS archive on sourceforge.net, see the Source access via
CVS page for details. When you check the sources out you will get
Python:dist:src, and under that the
Mac etc hierarchy. The
src folder can be renamed to
is what this document refers to as the "toplevel Python folder".
The CVS repository does not contain all the projects for the plugin modules,
these are built with
fullbuild.py normally. For this reason
it is probably a good idea to first build
which builds a fairly minimal interpreter, and then follow the
PythonCoreshared library to embed Python in another program, if your program can live with using GUSI for I/O. Use PythonCore in stead of your MSL C library (or, at the very least, link it before the normal C library).
MSL AppRuntime.Libruntime library (with properly set CFM initialization and termination routines). PythonCore uses
MSL Runtime.Lib, which is really intended for standalone programs but which we fool into working by providing a dummy main program. It is linked statically into PythonCore (and exported to the applications and plugins) so we do not have to distribute yet another shared library. Plugin modules use
MSL ShlibRuntime.Lib(not the dropin runtime: modules are never unloaded) and obtain the rest from PythonCore. PythonCore uses a non-standard initialization entry point,
__initialize_with_resources, to be able to obtain resources from the library file later on. Plugins can do the same (_tkinter does) or use the standard