[100699] trunk/dports/lang/tcl/Portfile

[Ned Deily]

In article <BB46B35E-8F74-4A84-A2DC-01179A97F209 at orcaware.com>,
 Blair Zajac <blair at orcaware.com> wrote:
> On Dec 21, 2012, at 1:02 PM, Ned Deily <nad at acm.org> 
> wrote:
> > I believe the bump to 8.6 broke Python's IDLE and other Tkinter-based 
> > apps when using tk +quartz (aka Tk Aqua).
> > 
> >   RuntimeError: tk.h version (8.6) doesn't match libtk.a version (8.5)
> 
> Doesn't this just mean a recompile is necessary?

With the updated Tcl/TK 8.6 ports, rebuilding Python does not seem to 
help.  It appears to be dynamically linking with the system Tk 8.5 
framework, not with the Macports Tk 8.6 library.  Prior to the 8.6 bump, 
the MacPorts Pythons did dynamically link to the MacPorts lib (I use a 
nonstandard prefix in my source builds):

# prior to version bump
$ port info tk
tk @8.5.13 (x11)
Variants:             [+]quartz, universal, (-)x11
[...]
$ otool -L $(/macports/bin/python2.7 -c "import _tkinter; 
print(_tkinter.__file__)")
/macports/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/
site-packages/_tkinter.so:
   /macports/lib/libtcl8.5.dylib (compatibility version 8.5.0, current 
version 8.5.12)
   /macports/lib/libtk8.5.dylib (compatibility version 8.5.0, current 
version 8.5.12)
[...]

# after bump and forcing a rebuild of Python 2.7
$ port info tk
tk @8.6.0 (x11)
Variants:             [+]quartz, (+)universal, (-)x11
[...]
$ otool -L $(/macports/bin/python2.7 -c "import _tkinter; 
print(_tkinter.__file__)")
/macports/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/
site-packages/_tkinter.so:
   /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl 
(compatibility version 8.5.0, current version 8.5.9)
   /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk 
(compatibility version 8.5.0, current version 8.5.9)
[...] 
 
> > Upstream, we have done no testing of Tk 8.6 Aqua with Python on OS X and 
> > make no claims that it is supported.  Tk 8.5 Aqua has been problematic 
> > enough for Python; we're certainly in no rush to move to 8.6, especially 
> > since Apple isn't shipping it.
> 
> Why would Apple not shipping it be a consideration?  We don't use that 
> consideration for other software.  I'm just curios, not invested in the end 
> decision.

Sorry, I don't have the time right now to dig into the MacPorts patches 
for building Python et al but, in a vanilla Python build, the 
detect_tkinter_darwin funciton in setup.py looks at the Current Version 
link in various Library/Frameworks/{Tcl,Tk}.framework locations to 
determine which version of Tck/Tk it links with before reverting to the 
Unix locations.  It's rather complicated and has been tweeked in various 
Python releases.  The basic idea, though, for the vanilla Python is to 
link with the same default Tcl/Tk version in the OS X version's SDK (8.4 
in 10.4 and 10.5, 8.5 in 10.6 through 10.8) but allow them to be 
overridden by a newer third-party Tcl/Tk (typically, ActiveTcl) install 
of the same major version in /Library/Frameworks.  Note, a framework 
install of Tcl/Tk allows multiple versions to be supported: OS X 10.6 
through 10.8 ship with both 8.4 and 8.5.  There's some more detail here:

http://www.python.org/download/mac/tcltk/

> >  I would recommend reverting to 8.5 as 
> > the default and/or making Tck/Tk 8.6 available as an option.
> I'm ok with reverting to 8.5, I just didn't want to do extra work in other 
> ports if not necessary.
> 
> BTW, besides MacPorts, do people use  Tcl/Tk much?

Python's builtin GUI library, Tkinter, uses Tk.  (And Python's builtin 
IDE, IDLE, uses Tkinter.)  To do so, it uses the Tcl C API to embed a 
Tcl interpreter inside of Python.  There are, no doubt, changes in that 
API for 8.6 yet to be discovered that will affect Python with the Tk 
Cocoa Aqua (quartz) variant.  We have run into some problems with pretty 
much every 8.5.x release since Apple and ActiveState started shipping 
the Cocoa version beginning with 10.6.  (The Apple 10.6 version of Tk 
8.5 is and remains pretty much totally broken.)

-- 
 Ned Deily,
 nad at acm.org