tcl port and thread anabling

[Ryan Schmidt]

On Jan 11, 2012, at 02:14, Gustaf Neumann wrote:

> Currently i am in the process of preparing several new ports that depend on a tcl with threads enabled. The current situation in MacPorts is that the thread-enabled version of tcl is a variant (ports install tcl +threads). This has several implications
> 
> a) Since one cannot depend on a variant, one has to document "prior to installation of this package, please install tcl with ports enabled". The expectation of a package user of a package depending on a threaded tcl (e.g. currently the port "aolserver") is that a "port install aolserver" does everything required.
> 
> One could add e.g. a pre-configure section to the thread-dependent package and bail out, when the installed tcl is not thread enabled and to install the proper "variant". This is at least bettern than crashing.
> 
> b) When a non-threaded tcl is installed, and one wants to "upgrade" to the threaded tcl, one has recompile all packages with thread support. if one has e.g. installed tcl without threads, installed then the port "xotcl" (which has thread support) then one should re-build xotcl based on the threaded install. Otherwise loads of the non-threaded xotcl-extension in a multithreaded tcl app (e.g. aolserver) will cause crashes (missing mutex protection). Similarly, even loads of non-thread-compiled tcl-dependent packages compiled without thread support can cause crashes when loaded into a thread-enabled tclsh. see [1]. Is there a recommended way to automate reinstallation? Are there other recommendations or other experiences from other ports?
> 
> The simplest approach is to ship tcl by default with threads enabled. While Tcl 8.4 was distributed on many platforms with threads disabled by default, this has changed with Tcl 8.5 (out since several years). Tcl 8.5 is shipped threaded by several distributions such as ActiveState [2] (all builds are threaded for Windows, Mac OS X and Unix), Redhat and Debian (up to my knowledge). The tcl portfile has a warning inside about threaded builds, but that might be a left-over from Tcl 8.4.
> 
> Any recommendations for (a) and (b)?
> 
> -gustaf neumann
> 
> [1] http://community.activestate.com/forum-topic/activetcl-non-thread-version-8-4-15
> [2] http://wiki.tcl.tk/1875


If enabling threads in tcl will not cause any problems, then we should remove the variant, enable threads all the time, and revbump tcl and all ports that use it to force a rebuild.

But if there is still a valid reason why we'd sometimes want threads and sometimes not, then really we should have a tcl-threads subport within the tcl port, work should be done so that both tcl and tcl-threads can be installed simultaneously and not conflict with one another, and all ports that use tcl should decide whether they want threads support or not and depend on either tcl or tcl-threads.