[lots of explanation ... Starkit ...]

[hopefully something about how to structure the directories for general use as well as what code is needed within starkit to find the right extension as well as right applications, etc.]

One approach would be to have directory structures for each platform being supported. The main piece of code might then ensure that only that tree is included in the auto_path. One could even have things broken down so that the directory structure was something like:

script only packages linux only packages windows only packages hp-ux only packages and so forth.

Then, the initial code could set auto_path appropriately based on the platform.

Anyone have some code dealing with this issue?

---

I learned some by unwrapping the snack.kit from sdarchive and looking within the lib/snack directory.

LV here's what snack.kit does. Inside the starkit, the directory layout is:

 snack.vfs
   lib/
	snack/
		Linux-x86
			snack.so
			sound.so
		SunOS-sparc
			snack.so
			sound.so
		Windows-x86
			snack.dll
			sound.dll
   main.tcl

 $ cat pkgIndex.tcl

 # return a platform designator, including both OS and machine
 proc platform {} {
    global tcl_platform
    set plat [lindex $tcl_platform(os) 0]
    set mach $tcl_platform(machine)
    switch -glob -- $mach {
	sun4* { set mach sparc }
	intel -
	i*86* { set mach x86 }
	"Power Macintosh" { set mach ppc }
    }
    return "$plat-$mach"
 }

 proc loadlib {dir package version} {
    global tcl_platform
    set lib $package[info sharedlibextension]
    return [file join $dir [platform] $lib]
 }

 package ifneeded snack 2.1 "[list load [loadlib $dir snack 2.1]];[list source [file join $dir snack.tcl]]"
 package ifneeded sound 2.1 [list load [loadlib $dir sound 2.1]]

---

i believe that the starkit article [1] by stevel has some suggestions about this topic.

One of the most common errors made by starkit authors is neglecting to specify all the package require statements the code truly needs. And the number one omission is the statement for Tk.

The reason this becomes a problem is because the most commonly used tclkit on Windows unfortunately does a silent

 package require Tk

as part of its operation. Developers don't realize their starkit code is missing this critical statement, and then when the starkit is used on a non-Windows platform, the code fails.

---

See also Starkits with Binary Extensions

---