diff options
-rw-r--r-- | Mac/OSX/README | 138 |
1 files changed, 72 insertions, 66 deletions
diff --git a/Mac/OSX/README b/Mac/OSX/README index 38a2370..7b71db4 100644 --- a/Mac/OSX/README +++ b/Mac/OSX/README @@ -7,19 +7,19 @@ It is rather terse and probably incomplete, please send me feedback. 1. Why would I want a framework Python in stead of a normal static Python? -------------------------------------------------------------------------- -The main reason is because you want to create GUI programs in Python. With -the exception of X11/XDarwin-based GUI toolkits it appears that all GUI programs +The main reason is because you want to create GUI programs in Python. With the +exception of X11/XDarwin-based GUI toolkits it appears that all GUI programs need to be run from a fullblown MacOSX application (a ".app" bundle). -While it is technically possible to create a .app without using frameworks -you will have to do the work yourself if you really want this. +While it is technically possible to create a .app without using frameworks you +will have to do the work yourself if you really want this. -A second reason for using frameworks is that they put Python-related items -in only two places: /Library/Framework/Python.framework and /Applications/Python. +A second reason for using frameworks is that they put Python-related items in +only two places: /Library/Framework/Python.framework and /Applications/Python. This simplifies matters for users installing Python from a binary distribution -if they want to get rid of it again. Moreover, due to the way frameworks -work a user without admin privileges can install a binary distribution in -his or her home directory without recompilation. +if they want to get rid of it again. Moreover, due to the way frameworks work +a user without admin privileges can install a binary distribution in his or +her home directory without recompilation. 2. How does a framework Python differ from a normal static Python? ------------------------------------------------------------------ @@ -34,14 +34,15 @@ Versions/Current and you will see the familiar bin and lib directories. ---------------------------- Yes, probably. If you want to be able to use the PythonIDE you will need to -get Waste, an all-singing-all-dancing TextEdit replacement, from www.merzwaren.com. -It will unpack into a folder named something like "Waste 2.1 Distribution". Make -a symlink called "waste" to this folder, somewhere beside your Python source -distribution (it can be "../waste", "../../waste", etc). - -If you want Tkinter support you need to get the OSX AquaTk distribution. If you -want wxPython you need to get that. If you want Cocoa you need to get pyobjc. -Because all these are currently in a state of flux please refer to +get Waste, an all-singing-all-dancing TextEdit replacement, from +www.merzwaren.com. It will unpack into a folder named something like "Waste +2.1 Distribution". Make a symlink called "waste" to this folder, somewhere +beside your Python source distribution (it can be "../waste", "../../waste", +etc). + +If you want Tkinter support you need to get the OSX AquaTk distribution. If +you want wxPython you need to get that. If you want Cocoa you need to get +pyobjc. Because all these are currently in a state of flux please refer to http://www.cwi.nl/~jack/macpython.html, which should contain pointers to more information. @@ -49,11 +50,11 @@ information. ------------------------------------- This directory contains a Makefile that will create a couple of python-related -applications (fullblown OSX .app applications, that is) in /Applications/Python, -and a hidden helper application Python.app inside the Python.framework, and -unix tools "python" and "pythonw" into /usr/local/bin. In addition -it has a target "installmacsubtree" that installs the relevant portions of the -Mac subtree into the Python.framework. +applications (fullblown OSX .app applications, that is) in +/Applications/Python, and a hidden helper application Python.app inside the +Python.framework, and unix tools "python" and "pythonw" into /usr/local/bin. +In addition it has a target "installmacsubtree" that installs the relevant +portions of the Mac subtree into the Python.framework. It is normally invoked indirectly through the main Makefile, as the last step in the sequence @@ -61,28 +62,28 @@ in the sequence 2. make 3. make frameworkinstall -This sequence will put the framework in /Library/Framework/Python.framework, -the applications in /Applications/Python and the unix tools in /usr/local/bin. +This sequence will put the framework in /Library/Framework/Python.framework, +the applications in /Applications/Python and the unix tools in /usr/local/bin. -Building in another place, for instance $HOME/Library/Frameworks if you have no -admin privileges on your machine, has only been tested very lightly. This can be done -by configuring with --enable-framework=$HOME/Library/Frameworks. The other two -directories, /Applications/Python and /usr/local/bin, will then also be deposited -in $HOME. This is sub-optimal for the unix tools, which you would want in $HOME/bin, -but there is no easy way to fix this right now. +Building in another place, for instance $HOME/Library/Frameworks if you have +no admin privileges on your machine, has only been tested very lightly. This +can be done by configuring with --enable-framework=$HOME/Library/Frameworks. +The other two directories, /Applications/Python and /usr/local/bin, will then +also be deposited in $HOME. This is sub-optimal for the unix tools, which you +would want in $HOME/bin, but there is no easy way to fix this right now. -Note that there are no references to the actual locations in the code or resource -files, so you are free to move things around afterwards. For example, you could -use --enable-framework=/tmp/newversion/Library/Frameworks and use /tmp/newversion -as the basis for an installer or something. +Note that there are no references to the actual locations in the code or +resource files, so you are free to move things around afterwards. For example, +you could use --enable-framework=/tmp/newversion/Library/Frameworks and use +/tmp/newversion as the basis for an installer or something. If you want to install some part, but not all, read the main Makefile. The -frameworkinstall is composed of a couple of sub-targets that install the framework -itself, the Mac subtree, the applications and the unix tools. +frameworkinstall is composed of a couple of sub-targets that install the +framework itself, the Mac subtree, the applications and the unix tools. -If you want to run the Makefile here directly, in stead of through the main Makefile, -you will have to pass various variable-assignments. Read the beginning of the Makefile -for details. +If you want to run the Makefile here directly, in stead of through the main +Makefile, you will have to pass various variable-assignments. Read the +beginning of the Makefile for details. 5. What do all these programs do? @@ -93,39 +94,42 @@ debugger, etc. PythonLauncher.app is a helper application that will handle things when you double-click a .py, .pyc or .pyw file. For the first two it creates a Terminal -window and runs the scripts with the normal command-line Python. For the latter -it runs the script in the Python.app interpreter so the script can do GUI-things. -Keep the "alt" key depressed while dragging or double-clicking a script to set -runtime options. These options can be set once and for all through PythonLauncher's -preferences dialog. +window and runs the scripts with the normal command-line Python. For the +latter it runs the script in the Python.app interpreter so the script can do +GUI-things. Keep the "alt" key depressed while dragging or double-clicking a +script to set runtime options. These options can be set once and for all +through PythonLauncher's preferences dialog. BuildApplet.app creates an applet from a Python script. Drop the script on it -and out comes a full-featured MacOS application. There is much more to this, to -be supplied later. Some useful (but outdated) info can be found in Mac/Demo. +and out comes a full-featured MacOS application. There is much more to this, +to be supplied later. Some useful (but outdated) info can be found in +Mac/Demo. -The commandline scripts /usr/local/bin/python and pythonw -can be used to run non-GUI and GUI python scripts from the command line, respectively. +The commandline scripts /usr/local/bin/python and pythonw can be used to run +non-GUI and GUI python scripts from the command line, respectively. 6. How do I create a binary distribution? ----------------------------------------- Note: this section is work-in-progress. -First, to make sure there's no contamination, it is best to remove your existing Python -installation (clear out /Library/Frameworks/Python.framework and /Applications/Python). -Also, after build/install is finished check that nothing has shown up in those two locations. +First, to make sure there's no contamination, it is best to remove your +existing Python installation (clear out /Library/Frameworks/Python.framework +and /Applications/Python). Also, after build/install is finished check that +nothing has shown up in those two locations. -Create a subdirectory of the main python directory, say build-pythondist. In there, run - ../configure --enable-framework=/tmp/pythondist/Library/Frameworks/Python.framework \ +Create a subdirectory of the main python directory, say build-pythondist. In +there, run + ../configure --enable-framework=/tmp/pythondist/Library/Frameworks \ LDFLAGS=-Wl,-x make make frameworkinstall -This installs a complete distribution set in /tmp/pythondist: in a framework build all other -pathnames are computed from the framework pathname. +This installs a complete distribution set in /tmp/pythondist: in a framework +build all other pathnames are computed from the framework pathname. -Note that the unix tools in /tmp/pythondist are wrong, these have to be removed, and the -installer post-install script should recreate them on the target system. Also, the .pyc and -.pyo files need to be removed: +Note that the unix tools in /tmp/pythondist are wrong, these have to be +removed, and the installer post-install script should recreate them on the +target system. Also, the .pyc and .pyo files need to be removed: rm -rf /tmp/pythondist/usr python.exe ../Mac/script/zappycfiles.py /tmp/pythondist @@ -136,13 +140,15 @@ TBD: documentation. 7. Odds and ends. ----------------- -The PythonLauncher is actually an Objective C Cocoa app built with Project Builder. -It could be a Python program, except for the fact that pyobjc is not a part of -the core distribution, and is not completely finished yet as of this writing. +The PythonLauncher is actually an Objective C Cocoa app built with Project +Builder. It could be a Python program, except for the fact that pyobjc is not +a part of the core distribution, and is not completely finished yet as of this +writing. -Something to take note of is that the ".rsrc" files in the distribution are not -actually resource files, they're AppleSingle encoded resource files. The macresource -module and the Mac/OSX/Makefile cater for this, and create ".rsrc.df.rsrc" files -on the fly that are normal datafork-based resource files. +Something to take note of is that the ".rsrc" files in the distribution are +not actually resource files, they're AppleSingle encoded resource files. The +macresource module and the Mac/OSX/Makefile cater for this, and create +".rsrc.df.rsrc" files on the fly that are normal datafork-based resource +files. - Jack Jansen, jack@oratrix.com, 12-Aug-02
\ No newline at end of file + Jack Jansen, jack@oratrix.com, 06-Sep-02
\ No newline at end of file |