Hi, A couple of months ago we were discussing whether to bundle Tcl 8.5 with MacPorts to get rid of the limitation to 8.4-features to preserve compatibility with older platforms. I have this change almost done in my working copy, but I have a few questions:
I'm currently planning on bundling Tcl, the Tcl Thread package (required for trace mode) and Tcllib. The latter is currently only required for term::ansi::send in trunk port(1) for the progress bars, but I think having this around can simplify further development in that we might be able to avoid re-inventing the wheel (e.g. when switching to a Tcl 8.6-compatible try). If we bundle Tcl, I assume we'd have to update the MacPorts installer .pkg with the licenses of Tcl[1], the Tcl thread package[2] and Tcllib[3]? When using our own copy of Tcl we can install the MacPorts Tcl packages directly into the Tcl library path (that would currently be $prefix/libexec/macports/lib/tcl8.5/ if I'm right). Am I right in assuming the macports1.0 symlink usually installed in /Library/Tcl can be removed then? In theory, doing that would also lift the requirement of executing macports_fastload.tcl from the correct path before doing 'package require macports 1.0', because the correct MacPorts installation prefix would no longer be chosen by the mcaports_fastload.tcl file, but the used Tcl interpreter? Of course the macports_fastload.tcl file also allegedly improves startup speed, so we might keep it for that reason. I'm currently planning to include tarballs of Tcl, the Tcl Thread package and Tcllib in the MacPorts source tree. Configure would then extract those packages. Is this appropriate or should I implement some way of downloading the correct package instead of committing it to SVN? The recent changes moving the Portfiles from the registry to the file system changed the install target in base/Makefile.in [4]. Shouldn't this change be reproduced in base/portmgr/dmg/postflight [5] (with appropriate changes to the MacPorts port)? When bundling Tcl with MacPorts I assume TCLSH and TCL_PACKAGE_DIR in this very postflight script should be changed. Should I hardcode the correct paths for prefix=/opt/local or re-inplace them? This change would remove support for the Tcl sqlite3 package from the Tcl interpreter used for MacPorts. From what I can see the only location where this is used is base/portmgr/autosubmit.tcl [6], which doesn't seem to be used. Note this doesn't affect the registry db because that uses the sqlite3 interface from C, not from Tcl. My working copy currently only installs binaries and libraries of the mentioned packages but skips the documentation, mostly for speed reasons. Do we want the documentation in the private Tcl prefix? [1] http://www.tcl.tk/software/tcltk/license.html [2] http://core.tcl.tk/thread/artifact/0a34f908f19f5964d58507240770539b1949617e [3] http://core.tcl.tk/tcllib/artifact/6c242233927ff0e536efc819a9f539716cc35637 [4] http://trac.macports.org/changeset/117407/trunk/base/Makefile.in [5] http://trac.macports.org/browser/trunk/base/portmgr/dmg/postflight [6] http://trac.macports.org/browser/trunk/base/portmgr/autosubmit.tcl -- Clemens Lang _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
