Landon Fuller wrote:
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
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.
Thanks,
Blair
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
