Purpose: to house a discussion from a system administrator point of view, rather than a developer view, on techniques, do's and don'ts, and so forth on the topic of managing the source and binary trees.
This page was inspired by this comp.lang.tcl message:
From: Larry Virden
Subject: How do YOU manage all the variations of Tcl in your environment? Date: Fri Feb 23 08:16:58 EST 2001
I continue to find this topic to be one that causes me headaches on a regular basis. Sometimes I need tcl with debugging symbols (to help maintainers debug a cash). I generally need tcl with shared libraries. Sometimes, however, static libraries are needed (for stand-alone, single file executables). I now find that some extensions (Tclblend and thread for instance) require Tcl with threads. And of course, now that I'm moving to Solaris 8, I suspect that I am going to need a 64 bit compile. And of course, there's always a possibile need for a version compiled with profiling. In the past, I've also had to worry about special core patches; I am not currently running with any of these, but I suspect that some of you may be.
And I'm not even GOING to go to the 'specialized combinations of Tcl linked with specific extensions'.
So do you create a separate install directory for each of these? Surely you don't, in general, keep separate source trees. However, what I've found is various Tcl extensions go poking around in the Tcl source directory and if they don't find the file they want, refuse to configure.
Looking for a discussion on alternatives.
To which one reply was:
From: [Erik Leunissen]
Happy to find someone expressing, what I've been feeling since I started using Tcl a year ago. I'd like to take the opportunity to catch on to this thread and extend the issue to a few more steps in the usage of Tcl and its extensions/components. A suggestion is offered at the end of this posting.
Where Larry Virden mentions the management of *already* *installed* combinations of Tcl-variants, I'd like to raise the issue of user-friendliness of the entire 'suite of available Tcl software' in general; this from the viewpoint of a user who wants to develop a specific application with some arbitrary mixed/diverse functionality. The latter is the reason why I explicitly include Tcl-extensions in the discussion.
The following related usage-steps may be distinguished:
Tcl-versions/variants and extensions
As for step 1:
When Tcl-users want to make a specific application, especially when some mixed/diverse functionality is involved, they need to find out: - what Tcl-extensions provide the functionality they need? - what Tcl-versions these extensions require? - what variant of Tcl does one need: threaded, symbols, ... things Larry mentioned already mentioned (with respect to managing the installed components)?
Related decisions: - is the user equipped to recompile source code when necessary? etc. - does the code need to run on more than one OS? - things I forgot ..?
The fact that : - you need to find out how the various extensions pose conditions to the Tcl-variant/version you need; - this information (as far as the extensions are concerned) is to be found scattered across the web;
... constitutes a rather inaccessible forest of information (well, actually I think one cannot call this 'information') to the less experienced Tcl users.
Especially users new to Tcl will have a hard time making the right choices here. I expect that they depend 'on a regular basis' on advice from c.l.t. or otherwise. I've got the impression that guidance in these choices could be offered in a more systematic way, at one location.
Steps 2, 3, and 4
Disregarding step 2 as a problem in itself, being unsure whether step 3 could be made more user friendly, and not intending to interfere with step 4 which has been launched by Larry Virden, I will limit my course, preliminary idea for enhanced user-friendliness to step 1 (though in relation to step 2):
Suggestion
What about some kind of guiding system for the selection process in step 1? I realize that the range of Tcl-extensions included and the level of detail of this guiding system needs to be chosen wisely. As for the location: The Tcl Developer Xchange could be extended at some point to provide this guidance.
Opinions, ideas
Volker Hetzer wrote:
Here (HPUX) we have /opt/tcltk/<version>. And /opt/tcltk/<version>/setup/tcltk.{sh,csh} In addition we've got a /opt/tcltk/setup/tcltk.{sh,csh} The setup files set PATH, MANPATH, TCLLIBPATH, TCL_LIBRARY, TK_LIBRARY and ISTR LD_LIBRARY_PATH or somesuch.
Whoever sources /opt/tcltk/setup/tcltk.{sh,csh} gets out current, approved tcl (it soueces just the setup file of the current version).
Whoever wants a different tcltk sources its setup and is done. Packages get recompiled for each version. Scripts generally start out working with the current setup and source their own, version specific setup as soon as problems arise:
#!/bin/sh # \ . /opt/tcltk/8.0.4/setup/tcltk.sh # \ exec tclsh "$0" "$@"
Bob Techentin wrote:
Actually, I do keep several source trees hanging around. Disk space is cheap.
Our unix sysadmins created a series of sh/csh "setup" scripts which allow users to easily specify the software packages they want to use. Each setup script checks prerequisites, sets environment variables, and (usually) adds something to PATH to make the requested package available. Most users put a number of "setup" commands in their .login, and may call others at the command line. "setup netscape" usually gets you the latest, while "setup netscape_4.5" can get you an earlier version. To make different versions of Tcl/Tk available, all I have to do is copy/create the setup shell scripts pointing to different directories.
So I tend to treat each Tcl/Tk installation separately. I'll create a README describing the whats and hows of that particular build, then a build script which un-tars, configures, and makes all the packages. Once I've got all the binary stuff in place, I'll typically copy a few Tcl-only or pre-built extensions into the libraries. On a good day, I add comments to the README explaining what I did.
Many readers with system administration responsibilities will also ask themselves related questions about Getting Tcl/Tk