mirror of https://github.com/python/cpython.git
1b2fe8e62b | ||
---|---|---|
.. | ||
Build | ||
README | ||
buildall |
README
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.)