new Makefile and everything
This commit is contained in:
parent
2d54692fcc
commit
1b2fe8e62b
119
Mac/MPW/README
119
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
|
||||
|
|
Loading…
Reference in New Issue