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