On Aug 16, 2007, at 12:10, Blair Zajac wrote:
I'm just trying to get a sense of what we're talking about here, as we're discussing trade offs between competing concerns. OK, then I'll simplify. Arguments For Moving: Developers can install multiple versions without passing -- with-tclpackage to configure (but they still have to pass a custom --prefix to configure) Arguments Against Moving: Placing the Tcl package in the standard Tcl package directory means that external tools can find the system MacPorts library out of the box. It seems to me like developers already have an easily solution to their problem. -landonf
I got these points.
Can you address the rest of the questions I asked in the previous note? That'll provide more context to make a choice.
How many tools are out there? I haven't used any of them, what are their names?
Don't know. How many tools and custom code out there uses zlib? The choice was originally made to support the GUI PortsManager app. I think it was a good choice.
How does that third party software even work if I do a --with- tclpackage? Does it break?
It would break unless the author endeavoured to support your non- standard Tcl package installation.
What about getting the third-party software to work with multiple MacPorts installs? How does that work?
See answer above.
It sounds like the third-party software should grow support to handle multiple MacPorts installs and the ability to point it at the root of an install and be able to find the TCL files it needs.
Except that nobody, other than developers, will be running multiple MacPorts installations. You're taking a simple fix to a simple problem: - Install MacPorts in the standard Tcl library directory, where external software can access it. And proposing a complex fix for a non-existent problem: Developers don't have to type an extra --with-tclpackage, and users have to set MACPORTS_HOME and tell any external software where to find the MacPorts installation I hold that this is an entirely aesthetically-driven bike shed. Unless there's a *really good reason* to change something, why don't we just leave it, and the original logic behind it, alone?
Right now with --with-tclpackage, if everybody puts them into their own path under $prefix, then there's almost no hope for the third- party software. If we standardize on a location in $prefix, then the user can point the software at a MacPorts install and except it to work.
So one remaining issue is how to get the third-party software to easily pick up the TCL files from a MacPorts install. It could check for a default location in /opt/local. Maybe use an environmental variable MACPORTS_HOME.
Setting environmental variables in the GUI is beyond the scope of most user's needs.