Tcl versions with threads enabled

Ryan Schmidt ryandesign at macports.org
Sun Feb 5 14:29:11 PST 2012


On Feb 4, 2012, at 03:20, Gustaf Neumann wrote:

> three weeks ago, i asked on macports-users how to proceed in cases where ports depending on Tcl with thread support should be realized. From my distant view, there are three options:
> 
> a) port variants (no good idea, since we can't have dependencies on these)
> b) making tcl threaded by default (my personal favorite, other tcl unix distros went this way)

If that doesn't cause any problems for any ports using Tcl, then that seems easiest.

> c) subports (not sure, if this is worth the potential confusion, when there are two version of the
>   same software release around, probably, one has to mangle names for the dylibs on macports)

Yes, we'd have to go to some lengths to allow both versions to be installed at the same time, by changing where the libraries, headers and binaries go and/or what they're called, then modify every port using Tcl to be aware of those differences. It would probably be a lot of work.

> Other usages of subports i have seen are for version number management.

Like what? I've not seen that.

Currently subports are primarily used to offer multiple versions of each python module -- one for each version of python -- but the version number of the module usually remains the same. Same for each perl module -- one subport for each version of perl.

Another useful application of subports is for software that contains multiple programs or libraries that you want the user to be able to install separately. For example, the pianobar port has a libpiano subport. The advantage here is that when you update the port to a new version, you only have to update the version and checksums in one place, and all subports inherit that change.

> Currently there is just a "tcl" port, no tcl8.4, tcl8.5 or tcl 8.6 port.

Correct; it was hoped that any software not compatible with tcl 8.5 would be updated soon to be compatible.

tcl 8.6 appears to be in beta; presumably, when it's finalized, the tcl port will be updated to version 8.6 (and then no port for version 8.5 will remain).

Alternately, we could decide to offer separate ports for each tcl version, like we already do for python and perl, if that is deemed to be useful.

> For this purpose, subports appear (to my limited knowlege) the way to go. Btw: Some of the ports depending on tcl fail currently due to the fact that they depend on tcl 8.4, but the "tcl" port is actually 8.5.
> 
> Is there any decision making process on the way? Anything i can do?
> 
> Is there anything i can do to accelerate the three tickets below?
> (all have a patch or Portfile attached, these are easy to test)
> 
> https://trac.macports.org/ticket/32858
> https://trac.macports.org/ticket/32859
> https://trac.macports.org/ticket/32899




More information about the macports-dev mailing list