Re: Problem building scotty 2.1.0

Greg A. Woods (woods@most.weird.com)
Wed, 26 Jun 96 12:33:06 -0400 (EDT)

[ On Wed, June 26, 1996 at 18:15:16 (+0200), Juergen Schoenwaelder wrote: ]
> Subject: Re: Problem building scotty 2.1.0
>
> You can edit the init.tcl file of your Tcl installation as described
> in the unix/README file if you prefer this solution.

No, no, that's the wrong "application" to fix! ;-)

> There are two problems: You have to edit *every* script file that uses
> a package and this makes script files not portable. IMHO, this kills
> the concept of packages completely.

Well, the first and most obvious question to ask would be why script
files need to be "portable" in this sense. Once the application is
configured and installed there should be no reason to keep the scripts
portable. If there's some unsurmountable reason that you can't have a
homogeneous view of the installed packages on every system from which
you might run the script, then so far as I know you can still fall back
on the environment variable hack.

It is also possible to custom install the "client" portion, i.e. the
scripts themselves. They are usually tiny, and I'm sure a simple
procedure could be added to make this relatively painless for folks who
do have wildly divergent workstation environments for whatever reason.

This is a little trickier for the scotty binary, but there are lots of
options here too, including the environment variable hack.

I'd like to know how many people wouldn't be able to make use of the
solution I implemented, esp. before I went any further to improve it.

> Once again, Tcl must have a way to find packages automatically. I
> already proposed to make Tcl smart enough to locate packages in
> $(exec_prefix)/lib automatically by assuming a naming convention

The obvious naming convention would be:

$(exec_prefix)/lib/tcl-pkgs/whatever

Then the search is as simple as a directory listing....

> (actually the way the tnm and tkined packages are installed). This is
> easy to implement, allows a package writer all sorts of freedom how a
> package loads and initializes itself and does not require to play
> dirty tricks with init.tcl. I really hope that the Tcl guys pick up
> such a solution.

This would be the best obvious solution. It's not as if it's a new idea
either -- I can hardly believe they haven't done this yet, but then we
are talking about John Ousterhout, aren't we -- he has been known to
have a bit of a stubborn streak! ;-)

> (BTW, I nearly spend a week playing with different
> installation schemes and you will have a hard time to convince me of a
> better way. :-)

I'd like to convince you to add my patches, or at least choose some
similar default solution. I think they will cover the general case for
now, and I think TCLLIBPATH will still work as the fall-back if the
pre-configured locations are wrong or vary from workstation to
workstation (someone needs to test this).

-- 
							Greg A. Woods

+1 416 443-1734 VE3TCP robohack!woods Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>