blob: f63b10645b62e2626d77369c0a390cbfcc467933 [file] [log] [blame]
Guido van Rossum8ce65b41994-08-29 08:58:39 +00001From: walker@island.com (Richard Walker)
2Date: Wed, 1 Jun 94 15:28:40 PDT
3
4Compiling Python Under MPW C
5============================
6
7This directory contains the Makefiles, source files and scripts
8required to compile Python under MPW C.
9
10Compiling:
11----------
12the "buildall" file at the top level is an MPW script
13which rebuilds the entire Python source.
14
15To build, start the MPW Shell and select the Worksheet window.
16Go to top level directory of the Python source tree.
17Type: buildall<ENTER>
18
19To rebuild:
20Type: buildall clean<ENTER>
21Type: buildall<ENTER>
22
23Configuration:
24--------------
25The files "Makefile", "config.h", "Modules:config.c" and
26"Modules:Makefile" are normally configured and/or generated
27automagically under Unix.
28
29Macintosh programmers will have to be content with editing
30these files manually to reflect their desired configuration.
31The files provided here are examples only; Modules which
32made it into this version are those which required little or
33no modification.
34
35Running:
36--------
37The top-level Makefile compiles Python as an MPW Tool.
38You can then run Python interactively from within
39the MPW Worksheet.
40
41Diagnostics:
42------------
43If Python fails to run by aborting in file "Parser:grammar1.c",
44at the end of the function "finddfa", line 46,
45try defining the preprocessor symbol "MPW_881_BUG" in
46file "Parser:acceler.c", function "fixstate", line 107.
47
Guido van Rossumc0af2aa1994-09-09 12:10:21 +000048---------------------------------------------------------------
49
50Additional notes by Guido for Python 1.1:
51-----------------------------------------
52
53I have tried this with MPW 3.2 and tweaked Richards Makefiles and
54buildall script slightly to work with Python 1.1. The same configure
55file now works for THINK C 6.0 and MPW 3.2. It is essential that
56'MPW' is defined when compiling with MPW; for both compilers,
57'HAVE_CONFIG_H' should also be defined. For MPW, the buildall script
58takes care of this.
59
60I moved some files around or renamed them and modified the Makefiles
61accordingly. All Mac specific files are now in the Mac subdirectory,
62especially config.c, config.h, macmodule.c, and (new) macmain.c.
63
64I wouldn't bother with the Grammar subdirectory or the Parser generator
65(Pgen) -- the needed Pgen output files are part of the distribution.
66
67If the buildall script stops at a compilation error you are usually
68left in one of the subordinate directories.
69
70Instead of using the buildall script you can also once execute the Set
71and Export commands listed at its top (which set compiler and linker
72options) and in each of the directories Mac, Parser, Python, Objects,
73Modules and finally the python rot directory, execute the two command
74
75 make >makefile.out
76 makefile.out
77
78Or you could execute
79
80 make
81
82have a look at its output and execute selected commands from it.
83
84The buildall script executes
85
86 Directory {Python}
87
88which normally prints the current directory, because {Python}
89is not defined. If it is set to the python root directory,
90you could place buildall somewhere in your command search path and
91execute it from anywhere.
92
93If you are mixing THINK C and MPW, you may experience weird errors
94in correct modules. These disappear when you throw away the
95module's .pyc file. The errors usually have to do with string
96literals containing '\n' or '\r'. The reason is an incompatibility
97between their handling of '\n' and '\r' -- in MPW C, '\n' actually is
98ASCII CR while '\r' is ASCII LF, which is the reverse situation from
99any other ASCII based C implementation. This behaviour is inherited
100by Python compiled with MPW C. This is normally not a problem,
101but *binary* files written by one system will be mis-interpreted
102by the other, and this is what happens to the .pyc files. There is no
103easy way to fix this in the source. (This is a real shame, since the
104format of .pyc files was carefully designed to be independent of
105byte order and integer size -- deviations in the ASCII character codes
106were never anticipated.)