Mirror
/
cpython
mirror of https://github.com/python/cpython
4
1
Fork 0
Code Issues Releases Wiki Activity

new Makefile and everything

This commit is contained in:
Guido van Rossum 1995-02-17 14:49:28 +00:00
parent 2d54692fcc
commit 1b2fe8e62b
1 changed files with 38 additions and 81 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

119
Mac/MPW/README
View File

@ -1,97 +1,54 @@
From: walker@island.com (Richard Walker) Python and MPW
Date: Wed, 1 Jun 94 15:28:40 PDT ==============
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 I've created a Makefile that does everything, plus a three-line Build
required to compile Python under MPW C. 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: I use these feature test macros:
----------
the "buildall" file at the top level is an MPW script
which rebuilds the entire Python source.
To build, start the MPW Shell and select the Worksheet window. MPW for all MPW compilers (e.g. long double in <math.h>)
Go to top level directory of the Python source tree. __SC__ for things specific to the Symantec C compiler
Type: buildall<ENTER> (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: MPW is defined in config.h (if it finds that applec is defined);
Type: buildall clean<ENTER> HAVE_UNIVERSAL_HEADERS is defined in macglue.h depending on whether it
Type: buildall<ENTER> thinks we are using Universal Headers. The others are defined by the
compiler or by the system headers.
Configuration: 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
The files "Makefile", "config.h", "Mac:config.c" and CD-ROM.
"Modules:Makefile" are normally configured and/or generated
automagically under Unix.
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: Applets
-------- =======
The top-level Makefile compiles Python as an MPW Tool.
You can then run Python interactively from within
the MPW Worksheet.
Diagnostics: (XXX This text file is on my Mac)
------------
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.
---------------------------------------------------------------
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 (XXX Need to check what convention SC uses -- I hope it uses Think's.)
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.
I moved some files around or renamed them and modified the Makefiles If you are mixing Think C and MPW, you may experience weird errors in
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
previously correct modules. These disappear when you throw away the previously correct modules. These disappear when you throw away the
module's .pyc file. The errors usually have to do with string module's .pyc file. The errors usually have to do with string
literals containing '\n' or '\r'. The reason is an incompatibility literals containing '\n' or '\r'. The reason is an incompatibility