cpython/Mac/MPW/README

107 lines
3.8 KiB
Plaintext
Raw Normal View History

From: walker@island.com (Richard Walker)
Date: Wed, 1 Jun 94 15:28:40 PDT
Compiling Python Under MPW C
============================
This directory contains the Makefiles, source files and scripts
required to compile Python under MPW C.
Compiling:
----------
the "buildall" file at the top level is an MPW script
which rebuilds the entire Python source.
To build, start the MPW Shell and select the Worksheet window.
Go to top level directory of the Python source tree.
Type: buildall<ENTER>
To rebuild:
Type: buildall clean<ENTER>
Type: buildall<ENTER>
Configuration:
--------------
The files "Makefile", "config.h", "Modules:config.c" and
"Modules:Makefile" are normally configured and/or generated
automagically under Unix.
Macintosh programmers will have to be content with editing
these files manually to reflect their desired configuration.
The files provided here are examples only; Modules which
made it into this version are those which required little or
no modification.
Running:
--------
The top-level Makefile compiles Python as an MPW Tool.
You can then run Python interactively from within
the MPW Worksheet.
Diagnostics:
------------
If Python fails to run by aborting in file "Parser:grammar1.c",
at the end of the function "finddfa", line 46,
try defining the preprocessor symbol "MPW_881_BUG" in
file "Parser:acceler.c", function "fixstate", line 107.
1994-09-09 09:10:21 -03:00
---------------------------------------------------------------
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.)