[Starkit]s and their interaction with binary [extension]s 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.

----
See also [sdx].

----
[Category Deployment] | [Category Tclkit]