On Aug 16, 2007, at 11:10, Blair Zajac wrote:
Landon Fuller wrote:
On Aug 16, 2007, at 10:55, Blair Zajac wrote:
Landon Fuller wrote:
On Aug 16, 2007, at 02:15, Anders F Björklund wrote:
For MacPorts 1.6, it might be a good idea to consider moving "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the @prefix_expanded@/share/macports/Tcl directory, in order to make the MacPorts installation self-contained within the designated prefix ?
If the "macports1.0" module needs to be in the system's Tcl package directory in order for other (inferior) software to find it, then can't this be accomplished by setting up a symbolic link ? e.g. /Library/Tcl/macports1.0 -> /opt/local/ share/macports/Tcl/macports1.0
I'll register a "please, no!". The whole point of putting macports in /Library/Tcl/macports1.0 was to support "inferior" software that needs to be able to find the system's macports installation, regardless of ${prefix}.
What software is this? Any third party tool that rightfully expects "package require macports" to work.
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