[Pythonmac-SIG] Building 32-bit on Snow Leopard with tkinter/IDLE (was: Recommended Tcl/Tk with Py-2.6.x)

[Ned Deily]

In article <1267993653.4b940c35c6297 at astrosun2.astro.cornell.edu>,
 Tom Loredo <loredo at astro.cornell.edu> wrote:
> Regarding building 32-bit *alone* on Snow Leopard, I've been having
> luck with this, based on a post in a Python bug tracker issue on
> readline problems:
> 
> ./configure --prefix=/usr/local/tmp --enable-framework\
>         BASECFLAGS="-arch i386" \
>         CFLAGS="-arch i386" \
>         LDFLAGS="-arch i386" \
>         MACOSX_DEPLOYMENT_TARGET=10.6
> 
> (of course, set the prefix as you need to).
> 
> It also works deploying for 10.5.  I'm not setting the universalsdk
> here, since I'm not building a universal binary; I hope I'm right
> that it's not necessary.  In any case, it's passing the expected
> tests.  I'm using Py-2.6.5rc1.

That looks like it should cover all the bases regarding "-arch" and 
should work.  As long as you are targeting the build just for the build 
machine and its current os level, you shouldn't need the sdk.  It might 
be nice to have a simpler configure option for this.  It wasn't a 
problem prior to 10.6 because everything ran by default in 32-bit mode 
so the explicit setting of -arch wasn't needed.
 
> I was really asking about how to build, on Snow Leopard, a 32-bit
> version with a *working* tkinter and IDLE.  I finally figured out
> a way to modify setup.py to do this (building against Apple's 
> Tcl/Tk 8.4).  It gives an i386 Python framework that passes the tcl
> tests, with a working IDLE.  I'll post the details shortly in case
> it's of use to anyone, but it's a kind of ugly hack.  I don't know
> if this is interesting enough that I should post the patch on
> the Python issue tracker; if so, I'd appreciate a pointer to a
> relevant thread.

The last time I played with the 10.6 Tk 8.4, it worked just fine, so, 
yeah, if you only need a 32-bit Tk on 10.6 that should be OK.  Earlier 
versions of Aqua Tk shipped with some previous versions of OS X were 
known to have problems so the standard workaround for that was to make 
sure the OS X installer was built on a machine with ActiveState's newer 
Tk 8.4 installed (in /Library/Frameworks/{Tcl,Tk}.frameworks).  Then on 
the installed machine when Tkinter is imported, OS X looks first in 
/Library/Frameworks/Tk... and, if necessary, falls backs to 
/System/Library/Frameworks/Tk...   Because the python.org installers are 
targeted to run on 10.3.9 through 10.6, they are still built this way.  
But, as Ronald points out, a more flexible scheme of dynamically using 
either 8.5 or 8.4 would be better.

(Sorry for the delay in responding: with 2.6.5, 3.1.2, and the final 2.7 
alpha releases all in play right now, it's been a little hectic trying 
to clear out some of the more pressing issues.)

-- 
 Ned Deily,
 nad at acm.org