[ 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
"tclConfig.sh".
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
${prefix}?
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@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@acm.org> <woods@robohack.ca> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@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@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.
This archive was generated by hypermail 2b29 : Thu Jan 03 2002 - 14:56:27 MET