| 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. |
| |
| --------------------------------------------------------------- |
| |
| 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.) |