Re: Problem building scotty 2.1.0

Bruce Barnett (barnett@grymoire.crd.ge.com)
Thu, 27 Jun 1996 10:06:40 -0400

As someone who just installed tcl/tk/scotty/tkined for the first time,
(because some less experienced people here spend several days trying to
do this, and failed), I have some suggestions. Perhaps I am looking at
this with a fresh view.

There are several conceptual difficulties with the installation that I faced.

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. As
I mentioned before, when I saw the command auto_mkindex, it sure looked
like an external script to me. I edited the init.tcl file, and TCL
complained about the index, and ignored it. So I examined the make
file, and notices the auto_mkindex command. I thne used find to locate
this file, and this did not work.

It took me a while to figure out that I had to execute the tclsh file
and type auto_mkindex while inside the program to "fix" the problem.

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.

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?

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.

I don't know how the current (fixed) installation works, but I expect
that I just copy the necessary files to a /usr/local/lib/<something>
and be done.

I hope the new version does not require an environment variable to be
set to install the software. That should not be necessary. This type
of installation procedure tends to cause "shot-gun" installation
techniques. If one administrator gets it working somehow, by changing
values in Makefiles, init.tcl, and environment variables, with
conflicting and/or redundant information, the next administrator will
have no clue how to re-install the package. Now we have a ticking
time-bomb, with code that is difficult to re-install, and maintain. 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.

The worst nightmare for a maintainer is to have code that cannot be
recreated from a fresh copy of the sources. Changing environment
variables, and patching init.tcl files to INSTALL the software is
wrong. These are steps that should be used to debug experimental code.
If this is the only choice, then it should be carefully and clearly
documented, so someone who has never heard of TCL can install it.

I sincerely hope the installation procedure can be improved.

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.