On 2014-3-3 21:51 , Clemens Lang wrote: > 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).
Sounds reasonable. > 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]? Yes. > 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. That does bring up one downside of the change: you can no longer just open the system tclsh and run 'package require macports'. Can be worked around with scripts or aliases or whatever of course. > 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? I would say keep it all in the repo, don't download it. Tarballs optional. They could be annoying if you want to look at or edit the source before configuring. > 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? (a) Yes, I made a note to update postflight at the same time as the Portfile. (b) postflight has a PREFIX variable you can use. > 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. Yeah. It does seem like working with the registry would be easier using sqlite from Tcl sometimes... but that's another story. - Josh _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
