Merging the various tweaks for MacPython-OS9 2.3a1 back into the trunk.

author: Jack Jansen <jack.jansen@cwi.nl> 2003-01-08 16:27:44 (GMT)
committer: Jack Jansen <jack.jansen@cwi.nl> 2003-01-08 16:27:44 (GMT)
commit: 3e82872ecaa642ff8bab89c4323d1c3b09981665 (patch)
tree: d0987955c48352ec147d6ad0113fe4845a578546 /Mac/Demo/building.html
parent: 6c64fa7ddadd7a3a24e8ddab7fd4ed9236fef1c3 (diff)
download: cpython-3e82872ecaa642ff8bab89c4323d1c3b09981665.zip
cpython-3e82872ecaa642ff8bab89c4323d1c3b09981665.tar.gz
cpython-3e82872ecaa642ff8bab89c4323d1c3b09981665.tar.bz2
1 files changed, 44 insertions, 95 deletions
diff --git a/Mac/Demo/building.html b/Mac/Demo/building.html
index d983461..06cf399 100644
--- a/Mac/Demo/building.html
+++ b/Mac/Demo/building.html
@@ -1,12 +1,12 @@
 <HTML>
 <HEAD>
-<TITLE>Building Mac Python from source</TITLE>
+<TITLE>Building MacPython-OS9 from source</TITLE>
 </HEAD>
 <BODY>
-<H1>Building Mac Python from source</H1>
+<H1>Building MacPython-OS9 from source</H1>
 <HR>
 
-This document explains how to build MacPython from source. This is
+This document explains how to build MacPython-OS9 from source. This is
 necessary if you want to make modifications to the Python core. Building
 Python is not something to be undertaken lightly, you need a reasonable
 working knowledge of the CodeWarrior development environment, a good net
@@ -23,10 +23,11 @@ once (and probably in the wrong place:-). <p>
 First a warning: this information may become outdated if a new CodeWarrior is
 released after MacPython. The 
 <a href="http://www.cwi.nl/~jack/macpython.html">MacPython homepage</a> will
-hopefully have updated instructions in that case. These instructions are for CW7.
+hopefully have updated instructions in that case. These instructions are for CW7,
+it is rumoured you may encounter some problems with newer versions of CodeWarrior.
 </blockquote>
 
-I am very interested in feedback on this document, send your
+I am interested in feedback on this document, send your
 comments to the <A
 HREF="http://www.python.org/sigs/pythonmac-sig/">Mac Python Special
 Interest Group</A>.
@@ -77,11 +78,6 @@ you need:
 
 <UL>
 
-<LI> Tcl and Tk are somewhat less supported on the Mac than on Unix
-or Windows.
-See the section on <A HREF="#tcltk">building Tcl/Tk Python</A>
-below.
-
 <LI> Waste, a TextEdit replacement written by Marco Piovanelli, <A
 HREF="mailto:piovanel@kagi.com">&lt;piovanel@kagi.com&gt;</A>.  Python
 was built using version 2.0, which is included in the CodeWarrior
@@ -132,7 +128,6 @@ Top-level-folder:
 			Modules
 			Build
 			...
-	Tcl/Tk Folder 8.3.4
 </PRE>
 
 If your setup of the libraries is exactly the same as mine (which is
@@ -142,7 +137,7 @@ repository) you can use the project <code>buildlibs.prj</code> in the
 fell swoop, otherwise you will have to build the libraries one by
 one. <p>
 
-First build GUSI, both the normal one and the Carbon variant.
+First build GUSI, the Carbon variant.
  <p>
 
 Next, in
@@ -152,35 +147,6 @@ and<code>libtiff</code> you build all projects. Usually the projects are in "mac
 subfolders, sometimes they are in the main folder. Tcl/tk is a special
 case, see below.
 
-<H2><A NAME="tcltk">Building Tcl/Tk</H2>
-
-Tkinter has been built with Tcl/Tk 8.3.4. Load the Mac source distribution
-from the tcl sourceforge site and build it. Build with CW7, but you will
-need CW6 to build the MDEF resource (or copy it from a binary
-installation). As of this writing the projects are CW6, so they need
-massaging to build with CW7, but this is a lot less work than applying
-all the workarounds for CW6 that the build instructions give. <P>
-
-Note that if you use a different release of Tcl and Tk than the ones
-I have used you may have to adapt the Python <code>tkresources.rsrc</code> file.
-This is easiest done by building <code>Tk8.3.shlb</code> and copying the TEXT, ICON
-and CRSR resources from it to <code>tkresources.rsrc</code>. This allows
-the <code>_tkinter</code> module to work without an installed Tk/Tcl on your
-machine. <P>
-
-Also note that the <code>_tkinter.ppc.slb</code> that is normally distributed
-in the <code>lib-dynload</code> folder is the one from the Imaging extension,
-which has some extra features needed by PIL (and which features should not
-hinder normal operation).
-
-</UL>
-
-Build first the Tcl library, then
-SimpleTcl (test it by typing <code>ls -l</code> in the window you get)
-then the Tk library, then SimpleTk (which can again be tested with
-<code>ls -l</code>). If this all worked you are all set to try
-building Python.
-
 <H2>The organization of the Python source tree</H2>
 
 Time for a short break, while we have a look at the organization of
@@ -212,7 +178,11 @@ on the Mac.
 <DD> Machine-independent modules in Python.
 
 <DT> Lib:lib-dynload
-<DD> This is where the Classic and Carbon dynamically-loaded plugin modules live.
+<DD> This is where the dynamically-loaded plugin modules live.
+
+<DT> Lib:plat-mac
+<DD> This is where most of the Mac-specific modules live. The modules here
+are available both in MacPython-OS9 and MacPython-OSX.
 
 <DT> Objects
 <DD> Machine-independent code for various object types. Most of these are
@@ -235,13 +205,13 @@ readme files, but more documentation is sorely needed.
 
 </DL>
 
-All the mac-specific stuff lives in the <code>Mac</code> folder:
+The mac-specific stuff lives in the <code>Mac</code> folder:
 <DL>
 <DT> Build
 <DD> This is where the project files live and where you build the
 libraries, shared libraries, executables and plugin modules. All the
 resulting binaries, except for intermedeate results, are deposited in
-the toplevel folder or the Mac:PlugIns folder (for plugin modules).
+the toplevel folder or the :Lib:lib-dynload folder (for plugin modules).
 
 <DT> Compat
 <DD> Unix-compatability routines. Most of these are not used anymore,
@@ -255,9 +225,8 @@ these if you are trying to build a non-GUSI python.
 <DD> Mac-specific but compiler-independent include files. 
 
 <DT> Lib
-<DD> Mac-specific standard modules. The <code>Carbon</code> package
-contains modules specifically needed with various MacOS toolbox
-interface modules, both for Carbon and classic PPC, despite the name.
+<DD> MacPython-OS9 specific standard modules which are not shared with
+MacPython-OSX.
 
 <DT> Modules
 <DD> Mac-specific builtin modules. Theoretically these are all
@@ -285,12 +254,10 @@ possibly changing the list of files included in the project window, of
 course).
 
 <DT> OSX
-<DD> Specific to unix-Python (also known as MachoPython) on OSX, not used
-by MacPython.
+<DD> Specific to MacPython-OSX, not used by MacPython-OS9.
 
 <DT> OSXResources
-<DD> Specific to unix-Python (also known as MachoPython) on OSX, not used
-by MacPython.
+<DD> Specific to MacPython-OSX, not used by MacPython-OS9.
 
 <DT> Python
 <DD> Mac-specific parts of the core interpreter.
@@ -316,33 +283,36 @@ but for more control over the freezing process you can run the main script here.
 </DL>
 
 <H2>Building the PPC interpreter</H2>
-<em>This is different since 2.1. You are best off using the fullbuild.py
-script, see <a href="#fullbuild">below</a>. </em><p>
 
-First you optionally build the external libraries with buildlibs.prj. Next, 
-the projects for
-interpreter and core library are linked together, so
-building the PythonInterpreterClassic and/or PythonInterpreterCarbon target
-in <code>PythonInterpreter.prj</code> 
-will result in everything being built. The result, however, is an "Application
-template", (filetype Atmp). If you don't use fullbuild you can manually
-turn either of these into an interpreter by copying it to PythonInterpreter
-and setting the filetype to APPL (with ResEdit or some such). <p>
+First you optionally build the external libraries with buildlibs.prj. <p>
+
+Then, the <code>fullbuild</code> script can be used to build
+everything, but you need a fully-functional interpreter before you can
+use it (and one that isn't rebuilt in the process: you cannot rebuild
+a running program). You could copy the interpreter to a different
+place and use that to run fullbuild. The <code>PythonStandSmall.prj</code>
+project builds an interpreter that is suited to this, and it can also come
+in handy if you need to debug things (which is easier in a static program). <p>
 
-Fullbuild does this for you, and the Atmp files is also how ConfigurePythonCarbon
-and ConfigurePythonClassic work their magic. <p>
+In case you want to build by hand, or in case the <code>fullbuild</code>
+script does not work, here is a breakdown of the various projects. <p>
+
+The projects for interpreter and core library are linked together, so
+building the PythonInterpreter target
+in <code>PythonInterpreter.prj</code> 
+will result in the whole core being built, but not the extension modules.  <p>
 
 You will get about 100 warnings on "missing prototype" for the various module init
 routines, ignore these. You will also get numerous warnings on functions from GUSI which
 override functions from MSL, ignore these too. <p>
 
-For completeness sake here is a breakdown of the projects:
+Here is a breakdown of the projects:
 
 <DL>
 
 <DT> PythonCore
 <DD> The shared library that contains the bulk of the interpreter and
-its resources. It has targets for PythonCore and PythonCoreCarbon.
+its resources.
 It is a good idea to immedeately put an alias to this
 shared library in the <code>Extensions</code> folder of your system
 folder.  Do exactly that: put an <em>alias</em> there, copying or
@@ -352,11 +322,7 @@ will also do this. <br>
 
 <DT> PythonInterpeter
 <DD> The interpreter. This is basically a routine to call out to the
-shared library. Unlike in previous releases the same program is used for
-creating applets (for which formerly PythonApplet was used). There are 4 targets
-in here: two for the classic and carbon templates (which are normally used, and
-converted to PythonInterpreter by the ConfigurePython* applets) and two
-for PythonInterpreter in it's classic and carbon version.<p>
+shared library. <p>
 
 <DT> Plugin projects
 <DD> Each plugin module has a separate project, and these can be rebuilt on
@@ -378,18 +344,6 @@ Finally, you must build the standard applets:
 fullbuild does this for you, but you can also manually drag/drop them onto
 BuildApplet. <p>
 
-<BLOCKQUOTE>
-<a name="fullbuild"></a>
-The <code>fullbuild</code> script can be used to build
-everything, but you need a fully-functional interpreter before you can
-use it (and one that isn't rebuilt in the process: you cannot rebuild
-a running program). You could copy the interpreter to a different
-place and use that to run fullbuild. The <code>PythonStandSmall.prj</code>
-project builds an interpreter that is suited to this, and it can also come
-in handy if you need to debug things (which is easier in a static program). <p>
-
-</BLOCKQUOTE>
-
 You are all set now, and should read the release notes and
 <code>ReadMe</code> file from the <code>Mac</code> folder.
 
@@ -411,16 +365,10 @@ also set (in the "binary files" section) "use mac encoding:
 applesingle" and (in the "text files" section) "use ISO latin 1
 conversion". <p>
 
-<blockquote>
-There is one group of people for whom MacCVS is not the best choice: people with
-checkin rights to the Python repository. You will have to use MacCVS Pro
-(completely unrelated) from www.maccvs.org, because it has working SSH support.
-</blockquote>
-
-It is a good idea to disable Quicktime Exchange in the Quicktime
-control panel. Quicktime Exchange will magically map some extensions to
-filetypes, and this can seriously hinder you if, for instance, <code>.bmp</code>
-is not a Windows bitmap file. <p>
+It is a good idea to disable Quicktime Exchange in the Quicktime control
+panel if you are on OS9 or before. Quicktime Exchange will magically map
+some extensions to filetypes, and this can seriously hinder you if, for
+instance, <code>.bmp</code> is not a Windows bitmap file. <p>
 
 The Python sources are checked out from the main
 Python CVS archive on sourceforge.net, see the <a
@@ -435,7 +383,7 @@ The CVS repository does not contain all the projects for the plugin modules,
 these are built with <code>fullbuild.py</code> normally. For this reason
 it is probably a good idea to first build <code>PythonStandSmall.prj</code>,
 which builds a fairly minimal interpreter, and then follow the
-<a href="#fullbuild">fullbuild instructions</a>.
+fullbuild instructions</a>.
 
 <H2>Odds and ends</H2>
 
@@ -446,7 +394,8 @@ Some remarks that I could not fit in elsewhere:
 <LI> It may be possible to use the <code>PythonCore</code> shared
 library to embed Python in another program, if your program can live
 with using GUSI for I/O. Use PythonCore in stead of your MSL C library
-(or, at the very least, link it before the normal C library).
+(or, at the very least, link it before the normal C library). Ask for help
+on PythonMac-SIG if you have problems with this.
 
 <LI> <a name="extending"></a>It is possible to build PPC extension
 modules without building a complete Python. The binary distribution
author	Jack Jansen <jack.jansen@cwi.nl>	2003-01-08 16:27:44 (GMT)
committer	Jack Jansen <jack.jansen@cwi.nl>	2003-01-08 16:27:44 (GMT)
commit	3e82872ecaa642ff8bab89c4323d1c3b09981665 (patch)
tree	d0987955c48352ec147d6ad0113fe4845a578546 /Mac/Demo/building.html
parent	6c64fa7ddadd7a3a24e8ddab7fd4ed9236fef1c3 (diff)
download	cpython-3e82872ecaa642ff8bab89c4323d1c3b09981665.zip cpython-3e82872ecaa642ff8bab89c4323d1c3b09981665.tar.gz cpython-3e82872ecaa642ff8bab89c4323d1c3b09981665.tar.bz2