Version 13 of Starkits with Binary Extensions

Starkits and their interaction with binary extensions are a bit of magic, but the simpler cases are quite easy to do and understand.

Simple case: Single platform, stubs enabled binary extensions with no external dependencies.

This is the easy case for packages like tdom or tktable, which do not depend on external .so or .dlls to work. Put the .so/.dll in the virtual filesystem and write/use a pkgIndex.tcl file that loads it when a package require is done. For many packages, copying the package subdir of /lib into the $::starkit::topdir/lib dir of the vfs is enough to make it work. (Windows users should note that DLL names in pkgIndex.tcl are case sensitive once wrapped into a .kit file, so a load which works when running against a .vfs directory may not work with a wrapped binary. - Twylite)

Example:

 # binary.tcl
 package require Tk
 package require Tktable
 puts "Loaded ok"

Wrap it and unwrap to create directory:

 sdx.kit qwrap binary.tcl
 sdx.kit unwrap binary.kit

Copy the binary Tktable libs in:

 cp /path/to/Tktable2.8 binary.vfs/lib

Rewrap the code:

 sdx.kit wrap binary

Medium case: Multiple platform, stubs enabled binary extension with no external dependencies.

Harder case: Single platform, stubs enabled binary extension with external dependencies.

Impossible case: Non stubs enabled, shared library binary extension.

Zarutian 31. july 2004: How portable are those extensions?

Depends. Many are just ANSI C, others are complex and interact with the platform.

LV What does portable mean to you? A binary extension, by its very nature, means that code using it will only run on platforms compatible with the binary portion of the code. So, if you want the code to run on 10 hardware/operating system platforms, you need to build the binaries for each of those combinations and make certain that the package loads appropriately.

snichols I noticed that starkits do not work with the binary Thread Tcl extension or support threaded Tcl scripts. I sort of got this working by putting all my Tcl code in main.tcl and putting the Lib folder outside the starkit. It's almost like a normal Threaded Tcl interpreter at this point. I'd prefer that starkits support Tcl threads with multiple source Tcl scripts and the lib folder could be included in the kit file.