JMN 2005-08-22
tarpack is an experimental Tcl-only package for loading & creating Tcl Modules that are also valid tar archives.
This is done by adding the 1st file in the archive with a special name.. such as the Tcl comment character # or a short piece of Tcl script. I chose "#tarpack-loadscript" as the 1st file's name and this also acts as a sort of file-type 'signature'.
This first file also contains the ctrl-z (\u001A) character as a terminator at the end so that Tcl can source the tar archive.
You can examine the .tm files with a text editor and any standard tar archiving programs to get a feel for what's going on.
It is available here: http://vectorstream.com/tcl/packages/ along with some other packages such as Thread, trofs & tdom wrapped using tarpack.. I refer to them as 'tarpacks'.
I've been playing around with Tcl Modules in an attempt to reduce interp startup time. For installations with a large number of packages on auto_path and/or with network connections on the auto_path, load time for packages can be significant.
I don't know how useful tarpack will end up being - It was intended to be tcl-only so that an installation including binary packages can be created such that all packages are Tcl Modules rather than the usual packages on auto_path.
I was initially playing around with trofs as an archiver - and presumably trofs as a binary package will be much more efficient, but by wrapping trofs with tarpack, I can at least bootstrap trofs into the system without relying on auto_path.
Like trofs tarpack doesn't depend on vfs, but unlike trofs, tarpack doesn't actually 'mount' the module as part of the filesystem.
LV Why avoid VFS?
Here's a rough example of how the Thread package was wrapped as a tarpack:
%package require tarpack 1.0 %tarpack::create Thread-2.6.1.tm [list ttrace.tcl Windows-x86 FreeBSD-x86] Thread-2.6.1.tm
At this point the tar archive (and Tcl Module!) Thread-2.6.1.tm has been created with a default basic load-script. This default load-script will simply source any .tcl files we gave in the list to tarpack::create above. If there were .so or .dll files directly listed there it would have called 'load' on them. (after copying out to file system)
The load-script is also left as a separate file in the working directory. It's named #tarpack-loadscript
This separate load-script can now be edited to make 'tarpack::source' & 'tarpack::load' calls to any of the wrapped files.
A subsequent tarpack::create call with the same arguments above will now use the modified load-script instead of the default. Alternatively
tarpack::update Thread-2.6.1.tm ""
will read the tar contents list of Thread-2.6.1.tm and re-archive them along with the modified load-script. (final arg is an empty list to indicate we are not adding any extra files)
Sorry there's no separate documentation - just some comments in the source.