[tkined] installing development version away from tcl/tk requires hacks...

Greg A. Woods woods-tkined-l at weird.com
Tue Aug 28 22:46:21 CEST 2001

[ On Tuesday, August 28, 2001 at 17:04:22 (+0200), Juergen Schoenwaelder wrote: ]
> Subject: Re: [tkined] installing development version away from tcl/tk requires hacks...
> The configure script tries to be smart - perhaps too smart. It tries
> to set the prefix by searching for scotty, tclsh8.3 and tclsh in that
> order. It looks like it finds tclsh8.3 or tclsh in /usr/pkg and there
> you are.

That's what I suspected!  ;-)

> This is probably not intuitive. However, if I remove this check, then
> it is more likely that people have to use the --with-tcl configure
> options to say where Tcl lives. Perhaps that is not bad either.

It would seem that if configure can find a "tclConfig.sh" in /usr/pkg
(I'm guessing my case it probably finds "tclsh" and/or tclsh8.3 in
/usr/pkg/bin, which is in my PATH and deduces the location from there?),
then that shouldn't necessarily affect the default setting of --prefix,
and I suppose more importantly vice versa -- the user-supplied --prefix
(alone without --with-tcl) shouldn't affect the search algorithm for

Perhaps what you're saying though is that --prefix is set with the
search for scotty|tclsh8.3|tclsh and then tclConfig.sh is found using

Would it be possible to search for tclsh8.3|tclsh and use that to search
for tclConfig.sh without setting ${prefix}?

I don't know what to think about using 'scotty' to default here.  It
might make it easier for someone with one instance installed in a
non-standard place to configure and build a new version, but I'll
commonly have at least two instances installed, one production version
in /usr/pkg, and a test version in /usr/local.

I think it's best to only default --prefix=/usr/local and to always
require an explicit override for any change.  Doing so would seem more
in line with the intentions of the Autoconf folks too....

> Tcl per default searches for packages where it has been installed. You
> can change this behaviour by editing scripts (like you did above) or
> by setting environment variables.

Ah ha!  I suspected there might be an environment variable I could set
to control this, though I've yet to discover its name....  There's
nothing in the tclsh(n) or wish(n) manual pages about this.

>From your hint below, and a new test, I now that I know I don't have to
exlicitly mention the package sub-directory and that "/usr/local/lib" is
sufficient.  That GREATLY simplifies things!  ;-)

> It looks more like a packaging issue
> which the various distributions have to sort out. (Perhaps you can
> convince the package maintainer to add /usr/local/lib to the default
> package search path - which would solve the problem for say 290 % of
> the cases.

Hmmm....  if the environment variable trick works well then that might
be enough (I can set it in /etc/profile for everyone except cron
scripts).  However if the package maintainers were to add at least
/usr/local/lib then that would certainly help a lot, and would make it
trivial for users of the packaged tcl/tk versions to install local stuff
outside the package hierarchy and still have it work automagically.
I'll mention this on the tech-pkg at netbsd.org list and see if it's agreed
to -- and from there the idea might migrate to other packaging systems
if they haven't already done something similar or better.

							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>     <woods at robohack.ca>
Planix, Inc. <woods at planix.com>;   Secrets of the Weird <woods at weird.com>
!! This message is brought to you via the `tkined & scotty' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <tkined-request at ibr.cs.tu-bs.de>.
!! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.

More information about the Tkined mailing list