Re: Problem building scotty 2.1.0

Juergen Schoenwaelder (schoenw@cs.utwente.nl)
Thu, 27 Jun 1996 18:18:55 +0200

barnett@grymoire.crd.ge.com (Bruce Barnett) wrote:

> First of all, there are several init.tcl files. Which one do I have to
> change? A find points me to the following files:

> /usr/local/tcltk/lib/tcl7.5/init.tcl
> /usr/local/tcltk/lib/tnm2.1.0/library/init.tcl
> /usr/local/tcltk/Src/scotty-2.1.0/tnm/library/init.tcl
> /usr/local/tcltk/Src/tcl7.5/library/init.tcl

> Now, which one do I change? And how? Editing the file didn't work.

Here is the text from the unix/README file:

: (f) Scotty and tkined installs as a dynamic loadable module. You have to
: make sure that the Tcl interpreter is able to find the modules on
: your system. There are two ways to achieve this goal:
:
: 1. You can use the Tcl environment variable TCLLIBPATH by setting
: it to the installation directories of the scotty and the tkined
: extension, e.g.
:
: TCLLIBPATH="/usr/local/lib/tnm2.1.0 /usr/local/lib/tkined1.4.0"
:
: 2. You can edit the Tcl initialization file init.tcl usually found
: as /usr/local/lib/tcl7.5/init.tcl and append the scotty and tkined
: directories to the Tcl auto_path variable, e.g.
:
: lappend auto_path /usr/local/lib/tnm2.1.0
: lappend auto_path /usr/local/lib/tkined1.4.0
:
: The first solution is useful for testing and playing with the scotty
: extension. If you are going to use scotty regularly and if there
: are multiple users who will be using scotty, the second version
: might be easier to use and administrate.

I think this text answers your questions. Perhaps my English is simply
too bad or it might be wrong to expect that people are reading README
files (at least if things are not working as they expect). Perhaps my
assumptions were wrong in this respect.

> Second, do I set the TCLLIBPATH to point to TCL, or to scotty? Scotty
> should know where it is, so my first impression is to modify it to tell
> me where TCL is.

Again, read the README file.

> Third, what exactly do I set the environment variable to? Should it
> contain the actual filename? Or the directory the filename is, or the
> directory that contains the library directory that contains the file.
> And is this the place where the sources are, or where the binaries are?
> Right now I have a directory called /usr/local/tcltk/lib/tnm2.1.0 and a
> file called /usr/local/tcltk/lib/tnm2.1.0. So, should the environment
> variable point to the directory, or the .so file? Or both?

Again, read the README file.

> As I mentioned before, if the error message said it was looking for
> file X in the following list of directories A, B, and C, it would be
> easier to fix the problem, without trying trial and error techniques.
> Otherwise, I might set the environment file to point to every directory
> I can think of, just so it stops complaining.

As I wrote before, this is a Tcl mechanism that happens *before*
scotty (or better tnm or tkined) gets control. I can't do anything
here. This is really a Tcl issue. I just refuse to hack around it
(like some other packages do) because you will run into much more
subtle problems later if the package maintainers are using
inconsistent ways to solve the problem.

> In our environment, if code can't be easily installed, our system
> administrators will not bother. They have hundreds of packages to
> install, and if it requires hours to install a software package, they
> give up.

I understand this point of view and I hope that the first patch will
solve the Makefile related bugs that have been reported. However, I
can't fix how Tcl does not find packages.

> It also sounds like we should raise this point to the TCL people. There
> should be a simple and standard way to add/install new packages. Once
> installed, each old user should not see any difference, everything
> works the same. But if someone wants to use the new package, they can.

Go ahead and report this Tcl problem to the Sun guys. They have to
finish the package stuff to make it "plug and play". Otherwise it
is mostly broken and unusable.

Juergen