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
|
---|