Bundling Tcl 8.5

[Joshua Root]

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