summaryrefslogtreecommitdiff
path: root/Mac/BuildScript/README.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Mac/BuildScript/README.txt')
-rw-r--r--Mac/BuildScript/README.txt33
1 files changed, 31 insertions, 2 deletions
diff --git a/Mac/BuildScript/README.txt b/Mac/BuildScript/README.txt
index fa04b97c56..6c08dbea7e 100644
--- a/Mac/BuildScript/README.txt
+++ b/Mac/BuildScript/README.txt
@@ -57,13 +57,42 @@ for each release.
* NCurses 5.9 (http://bugs.python.org/issue15037)
* SQLite 3.7.13
+ * Tcl 8.5.14
+ * Tk 8.5.14
* XZ 5.0.3
- uses system-supplied versions of third-party libraries
* readline module links with Apple BSD editline (libedit)
- - requires ActiveState Tcl/Tk 8.5.9 (or later) to be installed for building
+ - requires ActiveState Tcl/Tk 8.5.14 (or later) to be installed for building
+
+ * Beginning with Python 3.4 alpha2, this installer now includes its own
+ private copy of Tcl and Tk 8.5.14 libraries and thus is no longer
+ dependent on the buggy releases of Aqua Cocoa Tk 8.5 shipped with
+ OS X 10.6 or on installing a newer third-party version of Tcl/Tk
+ in /Library/Frameworks, such as from ActiveState. Because this
+ is a new feature, it should be considered somewhat experimental and
+ subject to change prior to the final release of Python 3.4. If it
+ is necessary to fallback to using a third-party Tcl/Tk because of
+ a problem with the private Tcl/Tk, there is a backup version of
+ the _tkinter extension included which will dynamically link to
+ Tcl and Tk frameworks in /Library/Frameworks as in previous releases.
+ To enable (for all users of this Python 3.4)::
+
+ sudo bash
+ cd /Library/Frameworks/Python.framework/Versions/3.4
+ cd ./lib/python3.4/lib-dynload
+ cp -p _tkinter.so.framework _tkinter.so
+ exit
+
+ To restore using Python's private versions of Tcl and Tk::
+
+ sudo bash
+ cd /Library/Frameworks/Python.framework/Versions/3.4
+ cd ./lib/python3.4/lib-dynload
+ cp -p _tkinter.so.private _tkinter.so
+ exit
- recommended build environment:
@@ -82,7 +111,7 @@ for each release.
considered a migration aid by Apple and is not likely to be fixed,
its use should be avoided. The other compiler, ``clang``, has been
undergoing rapid development. While it appears to have become
- production-ready in the most recent Xcode 4 releases (Xcode 4.4.1
+ production-ready in the most recent Xcode 4 releases (Xcode 4.6.3
as of this writing), there are still some open issues when
building Python and there has not yet been the level of exposure in
production environments that the Xcode 3 gcc-4.2 compiler has had.