On Mon, 3 Jul 2000, Brent Welch wrote:
Actually, there are a couple of problems.
In the case where an extension needs to bootstrap
Tcl, how does it tell Tcl where Tcl is installed?
It just seems strange to need to tell Tcl how
to init itself.
Some people have suggested using Tcl_FindExecutable(),
but what do you pass? The name of tclsh.exe? It may
not be installed. Folks could have just installed
tcl84.dll or whatever. Scott mentioned passing the
location of tcl84.dll to Tcl_FindExecutable(),
but if the dll is located somewhere on the PATH,
how would you know where that was? That assumes
that you also know what the name of the Tcl dll
is, so you would need to pass it into your
applicaiton or set a global variable. The
#1 problem people have with Tcl Blend is
incorrectly setting all the global variables
when running it under Windows. I provide a
shell script for Unix, but to do the same
for windows would require that everyone
download cygwin (people complain about that
too).
If an extension used stubs, I am not sure how
it could bootstrap itself. Would there be some
static bootstrap code compiled into the stub
enabled extension? Also, how would it know
which verison of Tcl it should load?
This is also a more general problem that Tcl
seems to have never really addressed. What
is "the right way" to install an extension
into a directory other than Tcl/lib?
For Tcl Blend, I have to set TCLLIBPATH
in a startup script call jtclsh. Oh and
don't even get me started on the fact
that extensions can not use --exec-prefix
because then the pkgIndex.tcl file will
not know where to find the shared lib.
Not to mention the fact that there is
no xplatform way to load a file, you
need to know the actual name of the
shared lib you are going to load.
It would be nice if there was "one true way"
to do this sort of thing. Oh and it needs
to work on all platforms too :)
Mo DeJong
Red Hat Inc
> It sounds like most of this is Windows specific, right Scott?
> What if we just cave in and set up basic registry structure
> under some vendor-neutral name, e.g., "Tcl" instead of Scriptics.
> At first I was pleased to see less dependency on the registry,
> but with examples like these, it seems like a few basic registry
> entries would simplify everyone's life.
>
> >>>"Scott Redman" said:
> >
> >
> > > -----Original Message-----
> > > > Sorry, I haven't been following this thread.
> > > >
> > > > You can't have any idea where the tclsh.exe lives,
> > > > unless it's in you're PATH or (on Windows) in the
> > > > registry. You can't even know the name (is it
> > > > tclsh.exe or tclsh83.exe?), maybe a global variable
> > > > or some sort of config file for your script can
> > > > help with that.
> > >
> > > What if there is no tclsh.exe file at all? I thought
> > > the point of stubs was to remove all the "junk" you
> > > needed to know about a version of Tcl. Can we
> > > just call Tcl_FindExecutable(NULL), will that
> > > still set up the tcl library path properly?
> >
> > You need to call Tcl_FindExecutable(<dll location>),
> > the NULL won't find the encoding directory but
> > should intitialize the basic encodings, and it
> > won't find the Tcl library on Unix. On Windows,
> > this can be automated in the DllMain() in tcl8x.dll,
> > but not on Unix (which will need an env variable
> > to figure it out). With stubs, you also need to
> > know where to pick up the tcl8x.dll and what number
> > the x is. An env variable (or registry on WinNT)
> > will solve this, just combine the two solutions.
> >
> > TCL_SHLIB=/usr/local/lib/libtcl83.so
> > TCL_SHLIB=c:\\Program Files\\tcl\\bin\\tcl83.dll
> >
> > This issue is also true for the Tcl Plugin, and
> > David Gravereaux had a working version that looked
> > at the registry on Windows, but this doesn't scale
> > to Unix. Each program could have it's own config
> > file instead, but I like it being common. If we
> > do this, then even tclsh can use it and be stubs
> > aware...
> >
> > I'm going to send this to the TEA list as well...
> >
> > -- Scott
> >
>
> -- Brent Welch <[EMAIL PROTECTED]>
> http://www.ajubasolutions.com
> Scriptics changes to Ajuba Solutions
> scriptics.com => ajubasolutions.com
>
> ----------------------------------------------------------------
> The TclJava mailing list is sponsored by Scriptics Corporation.
> To subscribe: send mail to [EMAIL PROTECTED]
> with the word SUBSCRIBE as the subject.
> To unsubscribe: send mail to [EMAIL PROTECTED]
> with the word UNSUBSCRIBE as the subject.
> To send to the list, send email to '[EMAIL PROTECTED]'.
> An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
>
>
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
