Although I can find no convention on this, it would seem tcl.h should probably be placed in /usr/include/tcl8.3, and tk.h in /usr/include/tk8.3. Debian puts them both in /usr/include/tcl8.3, but either way will save major headaches when tcl/tk 8.4 is released. Also the api to tcl/tk changes frequently, we need to provide a mechanism to have the developer choose the version of tcl/tk headers to include. We could possibly place a symlink from /usr/include/tcl8.3/tcl.h to /usr/include/tcl.h to provide backward compatibility, as well as in the future provide a mechanism for a default tcl.h header. Same goes for tk. Right now, there is no way to install tcl/tk 8.1 on my system without breaking tck/tk 8.3 other than installing in /usr/local/include.
tcl and tk are sep packages thus they get sep dirs ... i find the way it is currently setup to be the 'norm' on distro's ive used
Good suggestion, but as we only have one version of tcl, it's not a problem right now. Whenever 8.4 comes out and we get a package for it, we'll handle it then.
8.4 is out and a lot of people who want to use it find it's breaking other packages (which explains why it's still masked). I've written a couple of beta ebuilds for slotted tcl and tk. This will allow everybody to keep the old libraries for backward-compatability, and still take advantage of the new features in the language. TODO: * Write a tcltk-update script that allows the user to switch tcl-tk versions (see opengl-update). * Handle man pages and headers as mentioned in the original description for this bug. * Clean up this hack, possibly using tcltk-update to check for previously installed versions and create symlinks (and possibly move this functionality from src_install to pkg_postinst). I'm still new to writing ebuilds, so there's probably much more room for improvement.
Created attachment 21007 [details] tk-8.4.4-r1 beta 1
Created attachment 21008 [details] tcl-8.4.4-r1 beta 1
