From 1690409243aa369b998419d342468cb28a986b29 Mon Sep 17 00:00:00 2001 From: Jack Jansen Date: Thu, 16 Aug 2001 14:10:56 +0000 Subject: Updated to the current state of things (long overdue). --- Mac/Demo/building.html | 152 ++++++++++++++++++++----------------------------- 1 file changed, 61 insertions(+), 91 deletions(-) diff --git a/Mac/Demo/building.html b/Mac/Demo/building.html index 556eddd..6e381d9 100644 --- a/Mac/Demo/building.html +++ b/Mac/Demo/building.html @@ -6,12 +6,6 @@

Building Mac Python from source

-Note: This document is mostly still for Python 2.0, so -it is not correct. See the -MacPython homepage for an updated version, and if none is available -complain bitterly to me and work on it should progress faster. -

- This document explains how to build MacPython 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 @@ -41,10 +35,8 @@ The following things you definitely need:

The MacPython project files are configured to @@ -96,20 +84,18 @@ below. HREF="mailto:piovanel@kagi.com"><piovanel@kagi.com>. Python was built using version 2.0, which is included in the CodeWarrior package. You can also obtain it from <http://www.boingo.com/waste> +HREF="http://www.merzwaren.com/waste"><http://www.merzwaren.com/waste> and various other places.
  • Gdbm library for the Mac. Available from Jack's Mac software page at http://www.cwi.nl/~jack/macsoftware.html and -ftp://ftp.cwi.nl/pub/jack/mac. Also in the MacPython cvs repository at -lib-src/gdbm. +ftp://ftp.cwi.nl/pub/jack/mac.
  • JPEG library by the Independent JPEG Group. A version including Mac projects can be found at Jack's page mentioned above. The most recent JPEG library can always be obtained from ftp://ftp.uu.net/graphics/jpeg/. Again, -also in the MacPython cvs repository at lib-src/jpeg. +HREF="ftp://ftp.uu.net/graphics/jpeg/">ftp://ftp.uu.net/graphics/jpeg/.
  • The netpbm/pbmplus, libtiff, zlib and png libraries. The netpbm distribution (which includes libtiff) is generally available on Internet ftp @@ -117,9 +103,7 @@ servers. For Python pbmplus, an older incarnation of netpbm, is functionally identical to netpbm, since Python only uses the library and not the complete applications. A distribution with correct projects and library source only is available from, you guessed it, Jack's Mac software -page mentioned above. And, guessed it again, in the MacPython cvs repository -at lib-src/netpbm, etc. The only gotcha is that libtiff lives in -lib-src/netpbm/libtiff, for historical reasons. +page mentioned above. @@ -279,7 +263,7 @@ interface modules.
    Modules
    Mac-specific builtin modules. Theoretically these are all optional, but some are rather essential (like -macmodule). A lot of these modules are generated with +macosmodule). A lot of these modules are generated with bgen, in which case the bgen input files are included so you can attempt to regenerate them or extend them. @@ -327,40 +311,36 @@ but for more control over the freezing process you can run the main script here.
    Modules that are not supported any longer but may still work with a little effort. -

    Building the 68K interpreter

    - -68K Python is no longer supported, and the projects are not included in the -source distribution anymore. If you really want to build Python for the 68K -your best bet is to check the sources out of the CVS repository. The latest -projects (in :Mac:build:) that support 68K development are tagged as such, -and are dated around August 2000. If you plan on doing this announce it on -the SIG, please.

    -

    Building the PPC interpreter

    This is different under 2.1. You are best off using the fullbuild.py -script.

    +script, see below.

    + First you optionally build the external libraries with buildlibs.prj. Next, the projects for -interpreter, core library and applet skeleton are all linked together, so -building the PythonInterpreter target in PythonEngine.prj -will result in everything being built. The -resulting applications and fat shared library are deposited in the main -Python folder. Finally, you build all the plugins with the plugins.prj project. +interpreter and core library are linked together, so +building the PythonInterpreterClassic and/or PythonInterpreterCarbon target +in PythonInterpreter.prj +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).

    + +Fullbuild does this for you, and the Atmp files is also how ConfigurePythonCarbon +and ConfigurePythonClassic work their magic.

    For completeness sake here is a breakdown of the projects:

    -
    PythonCore (with subproject PythonCorePPC) +
    PythonCore
    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 +its resources. It has targets for PythonCore and PythonCoreCarbon. +It is a good idea to immedeately put an alias to this shared library in the Extensions folder of your system folder. Do exactly that: put an alias there, copying or moving the file will cause you grief later if you rebuild the library and -forget to copy it to the extensions folder again. The InstallPython applet -will also do this, along with creating the plugin aliases.
    -Note that the subproject looks a bit silly nowadays (with no more CFM68K -support) but you will have to live with that for this release. +forget to copy it to the extensions folder again. The ConfigurePythonXXX applets +will also do this.
    PythonInterpeter
    The interpreter. This is basically a routine to call out to the @@ -368,28 +348,28 @@ shared library. Unlike in previous releases the same program is used for creating applets (for which formerly PythonApplet was used).

    Plugin projects -
    Each plugin module has a separate project. The Plugins.prj -project tries to build them all, but is known to be flakey. See fullbuild -below for a better way to build everything. +
    Each plugin module has a separate project, and these can be rebuilt on +the fly. Fullbuild (or actually it's little helper genpluginprojects) takes +care of this.
    After creating the alias to PythonCore you remove any old -Python 2.0b1 Preferences file from the Preferences folder +Python XXXX Preferences file from the Preferences folder (if you had python installed on your system before) and run the interpreter once to create the correct preferences file.

    Next, you have to build the extension modules. -The PlugIns.ppc project has all the -other projects as subprojects and builds everything (but see the gotcha above). +If you don't use fullbuild simply open each project and build it.

    Finally, you must build the standard applets: -EditPythonPrefs, BuildApplet, etc. This is -easiest done with the fullbuild script from -Mac:scripts.

    +EditPythonPrefs, BuildApplet, etc. For the N-th time: +fullbuild does this for you, but you can also manually drag/drop them onto +BuildApplet.

    -Actually, the fullbuild script can be used to build + +The fullbuild 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 @@ -409,14 +389,17 @@ 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 +Rebuilding the .exp file is done by first both removing the file and removing the +reference to it in the project (in the "config" section). Next, build PythonCore or +PythonCoreCarbon. +This will create a new .exp file, with the name PythonCore.mcp.exp. +Rename this file to either PythonCore.exp or PythonCoreCarbon.exp +and add this file back to the project. Next, edit ot to remove the references to the symbols __initialize, __terminate, setjmp, -longjmp, vec_longjmp, main and (for PPC) __ptmf_null or (for -CFM68K) __start and dummy_init_routine. -Next, add the .exp file to the project -again and rebuild PythonCore.

    +longjmp, vec_longjmp, main and __ptmf_null. +They are all close together about halfway the file. + +Finally rebuild again.

    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 @@ -424,9 +407,6 @@ those routines have to be in the same code fragment as they are used from.

    Using the CVS source archive

    -Please check the MacPython homepage to see whether this information is -still current: MacPython should move to sourceforge shortly.

    - It is possible (and probably best) to access the Python sources through remote CVS. The advantage of this is that you get the very latest sources, so any bug fixed or new features will be immedeately available. This is also the @@ -441,41 +421,31 @@ also set (in the "binary files" section) "use mac encoding: applesingle" and (in the "text files" section) "use ISO latin 1 conversion".

    -It is also a good idea to disable Quicktime Exchange in the Quicktime +

    +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. +
    + +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, .bmp is not a Windows bitmap file.

    -The machine-independent Python sources are checked out from the main +The Python sources are checked out from the main Python CVS archive on sourceforge.net, see the Source access via CVS page for details. When you check the sources out you will get something like Python:dist:src, and under that the -Modules, Lib, etc hierarchy. The -src folder should be renamed to Python, and +Modules, Lib, Mac etc hierarchy. The +src folder can be renamed to Python, and is what this document refers to as the "toplevel Python folder".

    -Next, in a separate folder, you check out the -mac-specific sources. You then move the Mac folder from this -checkout (the only folder with anything in it) to the Python source folder. -Note that the checking out in a separate folder and moving is necessary, -due to the way cvs works. - -The CVS path to use for the mac stuff can be found -at the MacPython -homepage. Finally, you check out the external libraries needed in -the parent of the toplevel Python folder. The CVS path for these libraries is -also mentioned at the MacPython homepage.

    - - -You should end up with a folder structure as described at the top of this -document.

    - -Note that while the Mac folder is now a subfolder of your toplevel Python -folder this does not mean that they "act as one" as far as CVS is concerned. -To update all your sources you have to do a "cvs update" in the toplevel -Python folder and another one in the Mac folder. This is again a cvs problem: -it cannot deal with subpackages coming from different repositories.

    +The CVS repository does not contain all the projects for the plugin modules, +these are built with fullbuild.py normally. For this reason +it is probably a good idea to first build PythonStandSmall.prj, +which builds a fairly minimal interpreter, and then follow the +fullbuild instructions.

    Odds and ends

    -- cgit v0.12