| 1 | ============
 | 
|---|
| 2 | MacOSX Notes
 | 
|---|
| 3 | ============
 | 
|---|
| 4 | 
 | 
|---|
| 5 | This document provides a quick overview of some Mac OS X specific features in
 | 
|---|
| 6 | the Python distribution.
 | 
|---|
| 7 | 
 | 
|---|
| 8 | Mac-specific arguments to configure
 | 
|---|
| 9 | ===================================
 | 
|---|
| 10 | 
 | 
|---|
| 11 | * ``--enable-framework[=DIR]``
 | 
|---|
| 12 | 
 | 
|---|
| 13 |   If this argument is specified the build will create a Python.framework rather
 | 
|---|
| 14 |   than a traditional Unix install. See the section
 | 
|---|
| 15 |   _`Building and using a framework-based Python on Mac OS X` for more 
 | 
|---|
| 16 |   information on frameworks.
 | 
|---|
| 17 | 
 | 
|---|
| 18 |   If the optional directory argument is specified the framework it installed
 | 
|---|
| 19 |   into that directory. This can be used to install a python framework into
 | 
|---|
| 20 |   your home directory::
 | 
|---|
| 21 | 
 | 
|---|
| 22 |      $ configure --enable-framework=/Users/ronald/Library/Frameworks
 | 
|---|
| 23 |      $ make && make install
 | 
|---|
| 24 | 
 | 
|---|
| 25 |   This will install the framework itself in ``/Users/ronald/Library/Frameworks``,
 | 
|---|
| 26 |   the applications in a subdirectory of ``/Users/ronald/Applications`` and the
 | 
|---|
| 27 |   command-line tools in ``/Users/ronald/bin``.
 | 
|---|
| 28 | 
 | 
|---|
| 29 | * ``--with-framework-name=NAME``
 | 
|---|
| 30 | 
 | 
|---|
| 31 |   Specify the name for the python framework, defaults to ``Python``. This option
 | 
|---|
| 32 |   is only valid when ``--enable-framework`` is specified.
 | 
|---|
| 33 | 
 | 
|---|
| 34 | * ``--enable-universalsdk[=PATH]``
 | 
|---|
| 35 | 
 | 
|---|
| 36 |   Create a universal binary build of Python. This can be used with both
 | 
|---|
| 37 |   regular and framework builds.
 | 
|---|
| 38 | 
 | 
|---|
| 39 |   The optional argument specifies which OSX SDK should be used to perform the
 | 
|---|
| 40 |   build. This defaults to ``/Developer/SDKs/MacOSX.10.4u.sdk``, specify 
 | 
|---|
| 41 |   ``/`` when building on a 10.5 system, especially when building 64-bit code.
 | 
|---|
| 42 | 
 | 
|---|
| 43 |   See the section _`Building and using a universal binary of Python on Mac OS X`
 | 
|---|
| 44 |   for more information.
 | 
|---|
| 45 | 
 | 
|---|
| 46 | * ``--with-univeral-archs=VALUE``
 | 
|---|
| 47 | 
 | 
|---|
| 48 |   Specify the kind of universal binary that should be created. This option is 
 | 
|---|
| 49 |   only valid when ``--enable-universalsdk`` is specified.
 | 
|---|
| 50 | 
 | 
|---|
| 51 |   
 | 
|---|
| 52 | 
 | 
|---|
| 53 | Building and using a universal binary of Python on Mac OS X
 | 
|---|
| 54 | ===========================================================
 | 
|---|
| 55 | 
 | 
|---|
| 56 | 1. What is a universal binary
 | 
|---|
| 57 | -----------------------------
 | 
|---|
| 58 | 
 | 
|---|
| 59 | A universal binary build of Python contains object code for both PPC and i386
 | 
|---|
| 60 | and can therefore run at native speed on both classic powerpc based macs and
 | 
|---|
| 61 | the newer intel based macs.
 | 
|---|
| 62 | 
 | 
|---|
| 63 | 2. How do I build a universal binary
 | 
|---|
| 64 | ------------------------------------
 | 
|---|
| 65 | 
 | 
|---|
| 66 | You can enable universal binaries by specifying the "--enable-universalsdk"
 | 
|---|
| 67 | flag to configure::
 | 
|---|
| 68 | 
 | 
|---|
| 69 |   $ ./configure --enable-universalsdk
 | 
|---|
| 70 |   $ make
 | 
|---|
| 71 |   $ make install
 | 
|---|
| 72 | 
 | 
|---|
| 73 | This flag can be used with a framework build of python, but also with a classic
 | 
|---|
| 74 | unix build. Either way you will have to build python on Mac OS X 10.4 (or later)
 | 
|---|
| 75 | with Xcode 2.1 (or later). You also have to install the 10.4u SDK when 
 | 
|---|
| 76 | installing Xcode.
 | 
|---|
| 77 | 
 | 
|---|
| 78 | The option ``--enable-universalsdk`` has an optional argument to specify an
 | 
|---|
| 79 | SDK, which defaults to the 10.4u SDK. When you build on OSX 10.5 or later 
 | 
|---|
| 80 | you can use the system headers instead of an SDK::
 | 
|---|
| 81 | 
 | 
|---|
| 82 |   $ ./configure --enable-universalsdk=/
 | 
|---|
| 83 | 
 | 
|---|
| 84 | 2.1 Flavours of universal binaries
 | 
|---|
| 85 | ..................................
 | 
|---|
| 86 | 
 | 
|---|
| 87 | It is possible to build a number of flavours of the universal binary build,
 | 
|---|
| 88 | the default is a 32-bit only binary (i386 and ppc). The flavour can be
 | 
|---|
| 89 | specified using the option ``--with-universal-archs=VALUE``. The following
 | 
|---|
| 90 | values are available:
 | 
|---|
| 91 | 
 | 
|---|
| 92 |   * ``32-bit``:   ``ppc``, ``i386``
 | 
|---|
| 93 | 
 | 
|---|
| 94 |   * ``64-bit``:   ``ppc64``, ``x86_64``
 | 
|---|
| 95 | 
 | 
|---|
| 96 |   * ``all``:      ``ppc``, ``ppc64``, ``i386``, ``x86_64``
 | 
|---|
| 97 | 
 | 
|---|
| 98 |   * ``3-way``:    ``ppc``, ``i386`` and ``x86_64``
 | 
|---|
| 99 | 
 | 
|---|
| 100 |   * ``intel``:    ``i386``, ``x86_64``
 | 
|---|
| 101 | 
 | 
|---|
| 102 | To build a universal binary that includes a 64-bit architecture, you must build
 | 
|---|
| 103 | on a system running OSX 10.5 or later. The ``all`` flavour can only be built on
 | 
|---|
| 104 | OSX 10.5.
 | 
|---|
| 105 | 
 | 
|---|
| 106 | The makefile for a framework build will install ``python32`` and ``pythonw32`` 
 | 
|---|
| 107 | binaries when the universal architecures includes at least one 32-bit architecture
 | 
|---|
| 108 | (that is, for all flavours but ``64-bit``).
 | 
|---|
| 109 | 
 | 
|---|
| 110 | Running a specific archicture
 | 
|---|
| 111 | .............................
 | 
|---|
| 112 | 
 | 
|---|
| 113 | You can run code using a specific architecture using the ``arch`` command::
 | 
|---|
| 114 | 
 | 
|---|
| 115 |    $ arch -i386 python
 | 
|---|
| 116 | 
 | 
|---|
| 117 | Or to explicitly run in 32-bit mode, regardless of the machine hardware::
 | 
|---|
| 118 | 
 | 
|---|
| 119 |    $ arch -i386 -ppc python
 | 
|---|
| 120 | 
 | 
|---|
| 121 | NOTE: When you're using a framework install of Python this requires at least
 | 
|---|
| 122 | Python 2.7 or 3.2, in earlier versions the python (and pythonw) commands are
 | 
|---|
| 123 | wrapper tools that execute the real interpreter without ensuring that the
 | 
|---|
| 124 | real interpreter runs with the same architecture.
 | 
|---|
| 125 | 
 | 
|---|
| 126 | Building and using a framework-based Python on Mac OS X.
 | 
|---|
| 127 | ========================================================
 | 
|---|
| 128 | 
 | 
|---|
| 129 | 
 | 
|---|
| 130 | 1. Why would I want a framework Python instead of a normal static Python?
 | 
|---|
| 131 | --------------------------------------------------------------------------
 | 
|---|
| 132 | 
 | 
|---|
| 133 | The main reason is because you want to create GUI programs in Python. With the
 | 
|---|
| 134 | exception of X11/XDarwin-based GUI toolkits all GUI programs need to be run 
 | 
|---|
| 135 | from a fullblown MacOSX application (a ".app" bundle).
 | 
|---|
| 136 | 
 | 
|---|
| 137 | While it is technically possible to create a .app without using frameworks you
 | 
|---|
| 138 | will have to do the work yourself if you really want this.
 | 
|---|
| 139 | 
 | 
|---|
| 140 | A second reason for using frameworks is that they put Python-related items in
 | 
|---|
| 141 | only two places: "/Library/Framework/Python.framework" and 
 | 
|---|
| 142 | "/Applications/MacPython 2.6".  This simplifies matters for users installing 
 | 
|---|
| 143 | Python from a binary distribution if they want to get rid of it again. Moreover,
 | 
|---|
| 144 | due to the way frameworks work a user without admin privileges can install a 
 | 
|---|
| 145 | binary distribution in his or her home directory without recompilation.
 | 
|---|
| 146 | 
 | 
|---|
| 147 | 2. How does a framework Python differ from a normal static Python?
 | 
|---|
| 148 | ------------------------------------------------------------------
 | 
|---|
| 149 | 
 | 
|---|
| 150 | In everyday use there is no difference, except that things are stored in
 | 
|---|
| 151 | a different place. If you look in /Library/Frameworks/Python.framework
 | 
|---|
| 152 | you will see lots of relative symlinks, see the Apple documentation for
 | 
|---|
| 153 | details. If you are used to a normal unix Python file layout go down to
 | 
|---|
| 154 | Versions/Current and you will see the familiar bin and lib directories.
 | 
|---|
| 155 | 
 | 
|---|
| 156 | 3. Do I need extra packages?
 | 
|---|
| 157 | ----------------------------
 | 
|---|
| 158 | 
 | 
|---|
| 159 | Yes, probably.  If you want Tkinter support you need to get the OSX AquaTk 
 | 
|---|
| 160 | distribution, this is installed by default on Mac OS X 10.4 or later. If
 | 
|---|
| 161 | you want wxPython you need to get that. If you want Cocoa you need to get
 | 
|---|
| 162 | PyObjC. 
 | 
|---|
| 163 | 
 | 
|---|
| 164 | 4. How do I build a framework Python?
 | 
|---|
| 165 | -------------------------------------
 | 
|---|
| 166 | 
 | 
|---|
| 167 | This directory contains a Makefile that will create a couple of python-related
 | 
|---|
| 168 | applications (fullblown OSX .app applications, that is) in
 | 
|---|
| 169 | "/Applications/MacPython 2.6", and a hidden helper application Python.app 
 | 
|---|
| 170 | inside the Python.framework, and unix tools "python" and "pythonw" into 
 | 
|---|
| 171 | /usr/local/bin.  In addition it has a target "installmacsubtree" that installs 
 | 
|---|
| 172 | the relevant portions of the Mac subtree into the Python.framework.
 | 
|---|
| 173 | 
 | 
|---|
| 174 | It is normally invoked indirectly through the main Makefile, as the last step
 | 
|---|
| 175 | in the sequence::
 | 
|---|
| 176 | 
 | 
|---|
| 177 |  $ ./configure --enable-framework
 | 
|---|
| 178 |  $ make
 | 
|---|
| 179 |  $ make install
 | 
|---|
| 180 | 
 | 
|---|
| 181 | This sequence will put the framework in /Library/Framework/Python.framework,
 | 
|---|
| 182 | the applications in "/Applications/MacPython 2.6" and the unix tools in 
 | 
|---|
| 183 | /usr/local/bin.
 | 
|---|
| 184 | 
 | 
|---|
| 185 | It is possible to select a different name for the framework using the configure 
 | 
|---|
| 186 | option ``--with-framework-name=NAME``. This makes it possible to have several
 | 
|---|
| 187 | parallel installs of a Python framework.
 | 
|---|
| 188 | 
 | 
|---|
| 189 | Installing in another place, for instance $HOME/Library/Frameworks if you have
 | 
|---|
| 190 | no admin privileges on your machine, has only been tested very lightly. This
 | 
|---|
| 191 | can be done by configuring with --enable-framework=$HOME/Library/Frameworks.
 | 
|---|
| 192 | The other two directories, "/Applications/MacPython-2.6" and /usr/local/bin, 
 | 
|---|
| 193 | will then also be deposited in $HOME. This is sub-optimal for the unix tools, 
 | 
|---|
| 194 | which you would want in $HOME/bin, but there is no easy way to fix this right 
 | 
|---|
| 195 | now.
 | 
|---|
| 196 | 
 | 
|---|
| 197 | What do all these programs do?
 | 
|---|
| 198 | ===============================
 | 
|---|
| 199 | 
 | 
|---|
| 200 | "IDLE.app" is an integrated development environment for Python: editor,
 | 
|---|
| 201 | debugger, etc.
 | 
|---|
| 202 | 
 | 
|---|
| 203 | "PythonLauncher.app" is a helper application that will handle things when you
 | 
|---|
| 204 | double-click a .py, .pyc or .pyw file. For the first two it creates a Terminal
 | 
|---|
| 205 | window and runs the scripts with the normal command-line Python. For the
 | 
|---|
| 206 | latter it runs the script in the Python.app interpreter so the script can do
 | 
|---|
| 207 | GUI-things. Keep the "alt" key depressed while dragging or double-clicking a
 | 
|---|
| 208 | script to set runtime options. These options can be set once and for all
 | 
|---|
| 209 | through PythonLauncher's preferences dialog.
 | 
|---|
| 210 | 
 | 
|---|
| 211 | "BuildApplet.app" creates an applet from a Python script. Drop the script on it
 | 
|---|
| 212 | and out comes a full-featured MacOS application.  BuildApplet.app is now
 | 
|---|
| 213 | deprecated and has been removed in Python 3.  As of OS X 10.8, Xcode 4 no
 | 
|---|
| 214 | longer supplies the headers for the deprecated QuickDraw APIs used by
 | 
|---|
| 215 | the EasyDialogs module making BuildApplet unusable as an app.  It will
 | 
|---|
| 216 | not be built by the Mac/Makefile in this case.
 | 
|---|
| 217 | 
 | 
|---|
| 218 | The commandline scripts /usr/local/bin/python and pythonw can be used to run
 | 
|---|
| 219 | non-GUI and GUI python scripts from the command line, respectively.
 | 
|---|
| 220 | 
 | 
|---|
| 221 | How do I create a binary distribution?
 | 
|---|
| 222 | ======================================
 | 
|---|
| 223 | 
 | 
|---|
| 224 | Go to the directory "Mac/OSX/BuildScript". There you'll find a script 
 | 
|---|
| 225 | "build-installer.py" that does all the work. This will download and build
 | 
|---|
| 226 | a number of 3rd-party libaries, configures and builds a framework Python,
 | 
|---|
| 227 | installs it, creates the installer package files and then packs this in a
 | 
|---|
| 228 | DMG image.
 | 
|---|
| 229 | 
 | 
|---|
| 230 | The script will build a universal binary, you'll therefore have to run this
 | 
|---|
| 231 | script on Mac OS X 10.4 or later and with Xcode 2.1 or later installed.
 | 
|---|
| 232 | 
 | 
|---|
| 233 | All of this is normally done completely isolated in /tmp/_py, so it does not
 | 
|---|
| 234 | use your normal build directory nor does it install into /.
 | 
|---|
| 235 | 
 | 
|---|
| 236 | Because of the way the script locates the files it needs you have to run it
 | 
|---|
| 237 | from within the BuildScript directory. The script accepts a number of 
 | 
|---|
| 238 | command-line arguments, run it with --help for more information.
 | 
|---|
| 239 | 
 | 
|---|
| 240 | Configure warnings
 | 
|---|
| 241 | ==================
 | 
|---|
| 242 | 
 | 
|---|
| 243 | The configure script sometimes emits warnings like the one below::
 | 
|---|
| 244 | 
 | 
|---|
| 245 |    configure: WARNING: libintl.h: present but cannot be compiled
 | 
|---|
| 246 |    configure: WARNING: libintl.h:     check for missing prerequisite headers?
 | 
|---|
| 247 |    configure: WARNING: libintl.h: see the Autoconf documentation
 | 
|---|
| 248 |    configure: WARNING: libintl.h:     section "Present But Cannot Be Compiled"
 | 
|---|
| 249 |    configure: WARNING: libintl.h: proceeding with the preprocessor's result
 | 
|---|
| 250 |    configure: WARNING: libintl.h: in the future, the compiler will take precedence
 | 
|---|
| 251 |    configure: WARNING:     ## -------------------------------------- ##
 | 
|---|
| 252 |    configure: WARNING:     ## Report this to http://bugs.python.org/ ##
 | 
|---|
| 253 |    configure: WARNING:     ## -------------------------------------- ##
 | 
|---|
| 254 | 
 | 
|---|
| 255 | This almost always means you are trying to build a universal binary for
 | 
|---|
| 256 | Python and have libaries in ``/usr/local`` that don't contain the required
 | 
|---|
| 257 | architectures. Temporarily move ``/usr/local`` aside to finish the build.
 | 
|---|
| 258 | 
 | 
|---|
| 259 | 
 | 
|---|
| 260 | Uninstalling a framework install, including the binary installer
 | 
|---|
| 261 | ================================================================
 | 
|---|
| 262 | 
 | 
|---|
| 263 | Uninstalling a framework can be done by manually removing all bits that got installed.
 | 
|---|
| 264 | That's true for both installations from source and installations using the binary installer.
 | 
|---|
| 265 | Sadly enough OSX does not have a central uninstaller.
 | 
|---|
| 266 | 
 | 
|---|
| 267 | The main bit of a framework install is the framework itself, installed in
 | 
|---|
| 268 | ``/Library/Frameworks/Python.framework``. This can contain multiple versions
 | 
|---|
| 269 | of Python, if you want to remove just one version you have to remove the
 | 
|---|
| 270 | version-specific subdirectory: ``/Library/Frameworks/Python.framework/Versions/X.Y``.
 | 
|---|
| 271 | If you do that, ensure that ``/Library/Frameworks/Python.framework/Versions/Current``
 | 
|---|
| 272 | is a symlink that points to an installed version of Python.
 | 
|---|
| 273 | 
 | 
|---|
| 274 | A framework install also installs some applications in ``/Applications/Python X.Y``,
 | 
|---|
| 275 | 
 | 
|---|
| 276 | And lastly a framework installation installs files in ``/usr/local/bin``, all of
 | 
|---|
| 277 | them symbolic links to files in ``/Library/Frameworks/Python.framework/Versions/X.Y/bin``.
 | 
|---|
| 278 | 
 | 
|---|
| 279 | Odds and ends
 | 
|---|
| 280 | =============
 | 
|---|
| 281 | 
 | 
|---|
| 282 | Something to take note of is that the ".rsrc" files in the distribution are
 | 
|---|
| 283 | not actually resource files, they're AppleSingle encoded resource files. The
 | 
|---|
| 284 | macresource module and the Mac/OSX/Makefile cater for this, and create
 | 
|---|
| 285 | ".rsrc.df.rsrc" files on the fly that are normal datafork-based resource
 | 
|---|
| 286 | files.
 | 
|---|
| 287 | 
 | 
|---|
| 288 |         Jack Jansen, Jack.Jansen@cwi.nl, 15-Jul-2004.
 | 
|---|
| 289 |         Ronald Oussoren, RonaldOussoren@mac.com, 30-April-2010
 | 
|---|