65 lines
2.8 KiB
Plaintext
65 lines
2.8 KiB
Plaintext
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.)
|