RE: [tcltk-perl] Tcl-0.88 latest changes and plans
Brought to you by:
hobbs
From: Jeff H. <je...@Ac...> - 2005-07-19 00:04:54
|
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 |