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. _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
