summaryrefslogtreecommitdiffstats
path: root/Mac
diff options
context:
space:
mode:
authorGuido van Rossum <guido@python.org>1995-02-17 14:49:28 (GMT)
committerGuido van Rossum <guido@python.org>1995-02-17 14:49:28 (GMT)
commit1b2fe8e62bcc350adbd2faecc4c0819d92251365 (patch)
tree1e5de04d0851f0e6f6cd738ed02b1c5e5c9dbc59 /Mac
parent2d54692fcc291917f58d2112e9ed1b0f307b67d8 (diff)
downloadcpython-1b2fe8e62bcc350adbd2faecc4c0819d92251365.zip
cpython-1b2fe8e62bcc350adbd2faecc4c0819d92251365.tar.gz
cpython-1b2fe8e62bcc350adbd2faecc4c0819d92251365.tar.bz2
new Makefile and everything
Diffstat (limited to 'Mac')
-rw-r--r--Mac/MPW/README119
1 files changed, 38 insertions, 81 deletions
diff --git a/Mac/MPW/README b/Mac/MPW/README
index 8a59f1d..78e9140 100644
--- a/Mac/MPW/README
+++ b/Mac/MPW/README
@@ -1,97 +1,54 @@
-From: walker@island.com (Richard Walker)
-Date: Wed, 1 Jun 94 15:28:40 PDT
+Python and MPW
+==============
-Compiling Python Under MPW C
-============================
+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.
-This directory contains the Makefiles, source files and scripts
-required to compile Python under MPW C.
+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.
-Compiling:
-----------
-the "buildall" file at the top level is an MPW script
-which rebuilds the entire Python source.
+I use these feature test macros:
-To build, start the MPW Shell and select the Worksheet window.
-Go to top level directory of the Python source tree.
-Type: buildall<ENTER>
+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
-To rebuild:
-Type: buildall clean<ENTER>
-Type: buildall<ENTER>
+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.
-Configuration:
---------------
-The files "Makefile", "config.h", "Mac:config.c" and
-"Modules:Makefile" are normally configured and/or generated
-automagically under Unix.
+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.
-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.
+Applets
+=======
-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.
+(XXX This text file is on my Mac)
----------------------------------------------------------------
-Additional notes by Guido for Python 1.1:
------------------------------------------
+Warning: Mixing Think C and MPW
+===============================
-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 (or 7.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.
+(XXX Need to check what convention SC uses -- I hope it uses Think's.)
-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
+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