contents

Introduction - 1

Background - 2

Deployment - 3

Starkits - 4

Tclkit - 5

Advanced topics - 6

Repositories - 7

Server apps - 8

Who uses this - 9

Examples - 10

Conclusion - 11

Acknowledgements

References

4.3 - Using packages in Starkits

Using packages within a Starkit is only slightly different, and relies on the Tcl auto_path variable being set for us by the starkit::startup procedure.

As an example, we’ll modify our hello.tcl script to use gButtons - the fancy Tk buttons package - which is itself packaged as a Starkit.

There are two components we need to get from the gButtons Starkit - the gbutton and the autoscroll libraries. So, we download gButtons, unwrap it (using “sdx unwrap”) and copy both the lib/gbutton and lib/autoscroll packages to hello.vfs/lib. This gives us the new directory structure:

    hello.vfs
    |-- main.tcl
    `-- lib
        |-- app-hello
        |   |-- hello.tcl
        |   `-- pkgIndex.tcl
        |-- autoscroll
        |   |-- autoscroll.tcl
        |   `-- pkgIndex.tcl
        `-- gbutton
            |-- disabled.gif
            |-- down.gif
            |-- gbutton.tcl
            |-- pkgIndex.tcl
            `-- up.gif

Note that the gbutton directory includes both Tcl scripts and GIF images. A Starkit can contain scripts, images, data and (as we will see) binary extensions.

Note also that we don’t include version numbers in the directory name of each library. This convention is quite deliberate, and the rationale is both aesthetic and practical:

• the package version number is already encoded in both the pkgIndex.tcl and package Tcl scripts
• most applications only need one version of a package
• it is easier to upgrade to a later version (just by replacing files) without the need to rename directories
• in the unusual situation where there are multiple versions of the same package in an application, the directories of the older version(s) can contain version numbers, making it obvious which is the current version

Now we need a small modification to the hello.tcl script to use the new facilities. We’ll create a few buttons this time

    package provide app-hello 1.1
    package require Tk
    package require gbutton
    set buttons [gButton #auto .]
    $buttons new "Hello" bell
    $buttons new "Bonjour" bell
    $buttons new "Hola" bell

And now we wrap and use this as usual

    $ sdx wrap hello.kit

One other point to note is that the Starkit is compressed - for example on Unix we see the following sizes

    $ du -bs hello.vfs hello.kit
    64000   hello.vfs
    8192    hello.kit

So, adding packages to a Starkit is simply a matter of placing them under the lib directory, and invoking them in the usual way.

Binary extensions (i.e. platform specific shared libraries contained in packages) can be used under Starkits in the same way they can be used in any Tcl script. There is only one constraint - the extension must use the Tcl Stubs facility so that it can be dynamically loaded into the Tclkit interpreter.

The main downside is that binary extensions make a Starkit platform specific. But with a little care, it is possible to construct a cross-platform Starkit containing binary extensions for multiple platforms.

see also

• Starkit Home Page

• Tclkit Home Page

• Metakit Home Page

• SDX Utility

• Wikit Home Page

• Tclers' Wiki

• Author's Website

Updated paper, by Steve Landers, as presented at Tcl/Tk 2002 conference - see also original PDF.