| Python and MPW |
| ============== |
| |
| There is conditional code in Python for MPW. This has been used with |
| different compilers at various points in time. Right now it is being |
| used to turn the entire interpreter into a shared library on 68K Macs, |
| so we can build "applets". I have used MPW 3.2 and the OpenDoc |
| development environment from an OpenDoc CD released in 1984. This |
| contains the Symantec C compiler for MPW, version 7.XXX, the |
| Universal Headers version 2.0a1 (XXX), and early versions of CFM-68K |
| (the Code Fragment Manager ported back to the 68K Mac) and |
| MixedModeInit, which are required to use shared libraries. |
| |
| I've created a Makefile that does everything, plus a three-line Build |
| script that calls Make and runs its output. The Makefile assumes that |
| it lives in a 1-deep subdirectory of the root, so e.g. the Python |
| Include directory can be referenced through "::Include". All object |
| files are collected in the subsubdirectory Objcode. |
| |
| I use these feature test macros: |
| |
| MPW for all MPW compilers (e.g. long double in <math.h>) |
| __SC__ for things specific to the Symantec C compiler |
| (e.g. doesn't like static forward) |
| __CFM68K__ for things specific to CFM-68K |
| (e.g. it requires the use of #pragma lib_export on|off) |
| HAVE_UNIVERSAL_HEADERS for things not yet in Think's headers (e.g. UPPs) |
| GENERATINGCFM for both PPC and 68K Code Fragment Manager |
| |
| MPW is defined in config.h (if it finds that applec is defined); |
| HAVE_UNIVERSAL_HEADERS is defined in macglue.h depending on whether it |
| thinks we are using Universal Headers. The others are defined by the |
| compiler or by the system headers. |
| |
| Compiler switches were a nightmare until I found I had to use -b. |
| This wasn't mentioned in the CFM-68K docs that came on the OpenDoc |
| CD-ROM. |
| |
| |
| Applets |
| ======= |
| |
| (XXX This text file is on my Mac) |
| |
| |
| Warning: Mixing Think C and MPW |
| =============================== |
| |
| (XXX Need to check what convention SC uses -- I hope it uses Think's.) |
| |
| 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.) |