In article 
<[EMAIL PROTECTED]>,
 "Bob Ippolito" <[EMAIL PROTECTED]> wrote:

> >...
> > I've started looking into that. However, my strong suspicion is that the
> > way to build a MacPython installer that can use a user-installed Tcl/Tk
> > is to *have* a user-installed Tcl/Tk installed before building python
> > for the MacPython installer package.
> 
> That's one way, another is to use install_name_tool as part of the
> build procedure to change what _tkinter.so looks for, and a third is
> to include a subset of a recent Tcl/Tk in the build like the Win32
> installer does. The third option is ideal as far as how we do
> everything else goes.

I confess I've not figured out how this would work. Where would the 
installed Tcl/Tk go, to avoid colliding with a user-installed Tcl/Tk.

I'm a bit happier using a user-installed Tcl/Tk (if found) because it's 
still not completely stable and the user should easily be able to 
upgrade to a newer (less buggy) version if one comes along.

> Personally, I don't care much about this issue. I don't use Tcl/Tk
> Aqua, and it seems the only third party builds readily and obviously
> available are PPC-only, and I use a MacBook Pro. Creating a bug and/or
> patch makes it a lot more likely that something will happen
> (especially a patch).

I wasn't sure what to patch, so I submitted bug report #1563046.

The bug report includes a python script that (based on your recipe) 
modifies _tkinter.so to use a user-installed framework Tcl/Tk if it 
finds one.

I'm hoping the script will run as part of the installation of MacPython.

-- Russell

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Reply via email to