RE: [tcltk-perl] Tcl-0.88 latest changes and plans

[Jeff H. <je...@Ac...>]

Vadim Konovalov wrote:
> While doing this, I will cleanup my own ways, cleanup a bit=20
> Tcl::Tk WRT=20
> this, and also I created some PPM packages for intallation along with=20
> popular ActiveState's distributions:
>  - for usage when ActiveTcl is installed:
>      http://www.vkonovalov.ru/tcltk-misc/perl-TclTk-0.87.zip
>  - bundled with ActiveTcl (full and stripped a bit)
>       http://www.vkonovalov.ru/tcltk-misc/perl58-tcltk8410

Please don't bundle ActiveTcl, you will upset our legal
folks.  ;)  There are other options, possibly better ones
to look into.

> Along the way I notice quite many ways how searching of tcl84.dll is=20
> currently implemented but, to my understanding, some clarification=20
> should be done.
>=20
> There are two that bothered me.
>  - LIB_RUNTIME_DIR (could be specified in makefile.pl and is '.' by=20
> default)  How it is used?
> IMHO it is very little sence to search "tcl84.dll" relatively - a=20
> program could be started from everywhere and it is bad choice=20
> to depend on arbitrary files in arbitrary locations.

The default build type is to use the Tcl stubs mechanism,
which allows for version independence (build against Tcl X.y,
you can run against Tcl X.y+).

The LIB_RUNTIME_DIR is used when building with stubs to
indicate a default directory from which to try and load the
named Tcl dll specified in TCL_LIB_FILE.  For example, on
Windows LIB_RUNTIME_DIR could be 'C:\Tcl\bin' and
TCL_LIB_FILE would be 'tcl84.dll'.  This indirection through
stubs allows us to load tcl85.dll, tcl86.dll, etc. as well,
if tcl84.dll isn't found.

>  - using environment variable PERL_TCL_DLL. While quite=20
> simple and sane, how it is supposed to work?
> Something like - user invokes "use Tcl;" from perl script, then it=20
> calculates right tcl84.dll and then providing that path via=20
> environment variable PERL_TCL_DLL?

That would be correct.  PERL_TCL_DLL is the first checked
and overriding env var for indicating where the exact dll
the user wants to load is.  It is in fact designed to be an
absolute override - if it is set and that dll doesn't load
properly, the Tcl module will fail to load (with a proper
error message).

>  Is it actually used anywhere?

Yes, we use it for the Perl Dev Kit, which includes its own
prepackaged Tcl/Tk libraries, allowing it to be independent
of any other Tcl installation.  In fact, this is what you
should use if you want an optional "all-in-one" distro.
See below for details.

> One of two (or both) be either developed to robust state and=20
> documented, or removed and forgot :)

They are both valuable.  The above should be sufficient docs
for both cases.

> When these two items are done, it is quite easy to use Tcl for=20
> bootstrapping, so entire Perl is started from ZIP archive (and a few=20
> DLLs from outside archive)

When ActiveTcl is installed, you obviously don't have to
worry about what's available.  For some more reference to
the above code, you can see the original inspiration in the
Tcl web browser plugin loading functions:

http://cvs.sf.net/viewcvs.py/tclplugin/tclplugin/win/npWin.c?view=3Dmarku=
p
http://cvs.sf.net/viewcvs.py/tclplugin/tclplugin/unix/npUnix.c?view=3Dmar=
kup

as to an "all-in-one" wrapping solution, the best way is
likely to distribute a dll that is all you need.  In order
to do this, you must create a stardll (stand-alone runtime
dll).  Here is a script that creates one for the plugin:

http://cvs.sf.net/viewcvs.py/tclplugin/tclplugin/tools/buildkit.tcl?view=3D=
marku
p

Note that to do this, you require an ActiveState Tcl Dev Kit
license (specifically allows redistribution of the basekit
and basedll in ActiveTcl).  I'm willing to comp you a
license if you don't already have one (give me an email
address).

  Jeff Hobbs, The Tcl Guy
  http://www.ActiveState.com/, a division of Sophos