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