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.
Mac/mwerks/projects
for the project files and
related stuff.
Python:Mac:GUSI-mods
.
Mac:mwerks:mwerks_nonshared_config.h
file to remove the USE_...
line. Here are the locations for the various things
you need:
Top-level-folder: CWGUSI imglibs libjpeg pbmplus libtiff zlib libpng gdbm MoreFiles 1.4.3 (not needed by Python, only by tcl/tk) Python Tcl 7.6 Tk 4.2 Waste 1.2 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 projects
MSLGUSI.68K.µ
, MSLGUSI.CFM68K.µ
and
MSLGUSI.PPC.µ
.
If you have a CWGUSI version more recent than
1.8 it could be that the fixes are already included, check it.
Next, in
MoreFiles
, libjpeg
, pbmplus
,
zlib
, libpng
, gdbm
,
andlibtiff
you build all projects. Sometimes 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.
tcl7.6
and tk4.2
distribution:
compat
folders to (compat)
in both the Tcl and Tk folders.
strncasecmp.c
and
tclErrno.h
from (compat)
to the main Tcl
folder.
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.
SimpleTcl
and
SimpleTk
you may have to remove the references
to libmoto
from the project, not everyone has this library.
TclMacNotify.c
because there is an error in the Apple Universal headers (sic!). Read the
comments at the beginning of Mac:Python:macglue.c
and copy the
code to TclMacNotify.c
. If you get linker errors on GetEvQHdr
you have not done this correctly. XXXX Is this still needed?
tkresources.rsrc
file.
This is easiest done by building SimpleTk
and copying the TEXT, ICON
and CRSR resources from it to tkresources.rsrc
. This allows
the _tkinter
module to work without an installed Tk/Tcl on your
machine.
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.
ICCFMGlue.c
in folder Minimal IC
APIs
, add the following lines:
#include
#include
README-Mac
has some details.
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.
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.
Mac
folder:
toolbox
folder
contains modules specifically needed with various MacOS toolbox
interface modules.
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.
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).
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.
build.macppc.stand
. The order to build things is
the following:
Extensions
folder of your system
folder. Do exactly that: put an alias there, copying or
moving the file will cause you grief later.
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.
PythonCorePPC
you should move
PythonPPC
to the main Python folder. Next 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. You should also make an alias
PythonApplet
pointing to PythonAppletPPC
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
PythonAppletPPC).
Next, you have to build the extension modules in the
PlugIns
folder. Open each project with .ppc
in the
name 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. Run the MkPluginAliases.py
script from
Mac:scripts
to create the aliases.
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, theYou are all set now, and should read the release notes andfullbuild
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.Using fullbuild is also the only easy way to buid the fat application and applet. See the fullbuild source for details on how to build the fat binaries "by hand".
ReadMeOrSuffer
file from the Mac
folder.
.exp
files for PPC and CFM68K.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.
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 MSL C library
(or, at the very least, link it before the normal C library). Let me
know whether this works.
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
xx.ppc.µ
or xx.CFM68K.µ
.
MSL AppRuntime.Lib
runtime 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 __initialize
entry point.