mirror of
https://github.com/python/cpython.git
synced 2024-11-30 18:51:15 +01:00
108 lines
3.8 KiB
Plaintext
108 lines
3.8 KiB
Plaintext
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", "Mac: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.
|
|
|
|
---------------------------------------------------------------
|
|
|
|
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 (or 7.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
|
|
previously 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.)
|