---------------------------------------------------------------

Additional notes by Guido for Python 1.1:

-----------------------------------------

I have tried this with MPW 3.2 and tweaked Richards Makefiles and

buildall script slightly to work with Python 1.1. The same configure

file now works for THINK C 6.0 and MPW 3.2. It is essential that

'MPW' is defined when compiling with MPW; for both compilers,

'HAVE_CONFIG_H' should also be defined. For MPW, the buildall script

takes care of this.

I moved some files around or renamed them and modified the Makefiles

accordingly. All Mac specific files are now in the Mac subdirectory,

especially config.c, config.h, macmodule.c, and (new) macmain.c.

I wouldn't bother with the Grammar subdirectory or the Parser generator

(Pgen) -- the needed Pgen output files are part of the distribution.

If the buildall script stops at a compilation error you are usually

left in one of the subordinate directories.

Instead of using the buildall script you can also once execute the Set

and Export commands listed at its top (which set compiler and linker

options) and in each of the directories Mac, Parser, Python, Objects,

Modules and finally the python rot directory, execute the two command

make >makefile.out

makefile.out

Or you could execute

make

have a look at its output and execute selected commands from it.

The buildall script executes

Directory {Python}

which normally prints the current directory, because {Python}

is not defined. If it is set to the python root directory,

you could place buildall somewhere in your command search path and

execute it from anywhere.

If you are mixing THINK C and MPW, you may experience weird errors

in correct modules. These disappear when you throw away the

module's .pyc file. The errors usually have to do with string

literals containing '\n' or '\r'. The reason is an incompatibility

between their handling of '\n' and '\r' -- in MPW C, '\n' actually is

ASCII CR while '\r' is ASCII LF, which is the reverse situation from

any other ASCII based C implementation. This behaviour is inherited

by Python compiled with MPW C. This is normally not a problem,

but *binary* files written by one system will be mis-interpreted

by the other, and this is what happens to the .pyc files. There is no

easy way to fix this in the source. (This is a real shame, since the

format of .pyc files was carefully designed to be independent of

byte order and integer size -- deviations in the ASCII character codes

were never anticipated.)