From 27b10eced7a7ec00178042bef5d74b2bf81551af Mon Sep 17 00:00:00 2001 From: Jack Jansen Date: Fri, 23 Aug 1996 15:44:18 +0000 Subject: - Added cfm68k instructions - Changed names of various things - Explain how to recreate .exp files. --- Mac/Demo/building.html | 82 +++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 67 insertions(+), 15 deletions(-) diff --git a/Mac/Demo/building.html b/Mac/Demo/building.html index 036ff91..73e3d4e 100644 --- a/Mac/Demo/building.html +++ b/Mac/Demo/building.html @@ -57,12 +57,13 @@ It is possible to build a non-GUSI Python, see below. The MacPython project files are configured to include a plethora of optional modules, and these modules need a number extra packages. To use the project files as-is you have to -download these packages too. PPC Python has all such modules as +download these packages too. PPC and CFM68K Python have all such modules as dynamically loaded modules, so if you don't need a certain package it -suffices to just refrain from builing the extension module. For 68K +suffices to just refrain from builing the extension module. For static 68K Python things are a bit more complicated: you have to edit the interpreter project file to remove the reference to the module (and -the libraries it uses). Here are the locations for the various things +the libraries it uses), and edit the Mac:mwerks:mwerks_nonshared_config.h +file to remove the USE_... line. Here are the locations for the various things you need: Build first the MoreFiles library, then the Tcl library, then @@ -187,11 +195,15 @@ folders:
build.mac68k.stand -
This is where you will build 68K interpreters. +
This is where you will build static 68K interpreters. + +
build.mac68k.shared +
This is where you build the CFM68K shared library, interpreter +and applet framework.
build.macppc.shared
This is where you build the PPC shared library, interpreter and -applet framework. +applet framework. You can also build the fat applet framework here.
build.macppc.stand
This is where you build a nonshared PPC interpreter (optional). @@ -225,7 +237,7 @@ not really optional: the interpreter will not function without them.
The Python parser (machine-independent).
PlugIns -
This is where you build the PPC dynamically-loaded plugin modules. +
This is where you build the PPC and CFM68K dynamically-loaded plugin modules.
Python
The core interpreter. Most files are machine-independent, some @@ -318,6 +330,12 @@ distribution. Read the release notes (Relnotes-somethingorother) and ReadMeOrSuffer in the Mac folder. +

Building the CFM68K interpreter

+ +Building the CFM68K interpreter is as almost exactly the same as building +the PPC interpreter, with the exception that you should read "CFM68K" +for "PPC" every time. Continue reading with the next section. +

Building the PPC interpreter

First you build the interpreter, core library and applet skeleton in @@ -325,12 +343,12 @@ folder build.macppc.stand. The order to build things is the following:
-
PythonCoreRuntime +
MWRuntimeStaticLib
A modified version of the MetroWerks runtime library that is suitable for Pythons' shared library architecture. The sources all come from the MW distribution. -
PythonCore +
PythonCorePPC
The shared library that contains the bulk of the interpreter and its resources. It is a good idea to immedeately put an alias to this shared library in the Extensions folder of your system @@ -366,11 +384,12 @@ cause the correct file to be used if you ever rebuild PythonApplet).

Next, you have to build the extension modules in the -PlugIns folder. Open each project and build it. After all +PlugIns folder. Open each project with .ppc in the +name and build it. After all the dynamically loaded modules are built you have to create a number of aliases: some modules live together in a single dynamic -library. Copy or move the MkPluginAliases.py script from -Mac:scripts to the main python folder and run it.

+library. Run the MkPluginAliases.py script from +Mac:scripts to create the aliases.

Finally, you must build the standard applets: EditPythonPrefs, mkapplet, etc. This is @@ -391,6 +410,24 @@ this use only. You are all set now, and should read the release notes and ReadMeOrSuffer file from the Mac folder. +

Rebuilding .exp files for PPC and CFM68K

+ +Occasionally it may be necessary to rebuild your PythonCore .exp +file, a file that controls which symbols are exported by your PythonCore +shared library. Rebuild it if you get unexpected undefined symbols when you +are building a plugin module.

+ +Rebuilding the .exp file is done by first removing the file and removing the +reference to it in the project (in the "config" section). Next, build PythonCore. +This will create a new .exp file. Edit this file to remove the references to +the symbols __initialize, __terminate, setjmp, +longjmp and __ptmf_null. Next, add the .exp file to the project +again and rebuild PythonCore.

+ +This rather convoluted procedure is needed to ensure that plugin modules don't +accidentally link with those entrypoints from PythonCore, which will not work because +those routines have to be in the same code fragment as they are used from. +

Odds and ends

Some remarks that I could not fit in elsewhere: @@ -408,7 +445,22 @@ complete Python. Take the binary distribution, add folders Include, Mac:Include and Mac:mwerks from the source distribution and you should be all set. A template for a dynamic module can be found in -xxmodule.µ. +xx.ppc.µ or xx.CFM68K.µ. + +
  • The Python shared library architecture is a variant of the architecture +described as "application with shared libraries and dropins" in the MetroWerks +"Targeting MacOS" documentation. The Python Application and applet-template use +the AppRuntime.Lib runtime library (with properly set CFM +initialization and termination routines). PythonCore uses ShlibRuntime.Lib +and MWRuntimeStaticLib.Lib, which is almost identical to the MW +standard MWRuntimeLib, but not dynamically loaded. This library contains +the part of the runtime that can (or must) be shared between all modules in the program. +It is linked statically into PythonCore (and exported to the applications and plugins) +so we do not have to distribute yet another shared library. Plugin modules use +ShlibRuntime.Lib and obtain the rest from PythonCore. PythonCore uses a +non-standard initialization entry point, __initialize_with_resources, to +be able to obtain resources from the library file lateron. Plugins can do the same or +use the standard __initialize entry point.
      -- cgit v0.12