Next: , Previous: Features, Up: Top


3 Packages

gnu Smalltalk includes a packaging system which allows one to file in components (often called goodies in Smalltalk's very folkloristic terminology) without caring of whether they need other goodies to be loaded first.

The packaging system is implemented by a Smalltalk class, PackageLoader, which looks for information about packages in the XML file named (guess what) packages.xml, in one of three places:

There are two ways to load something using the packaging system. The first way is to use the PackageLoader's fileInPackage: and fileInPackages: methods. For example:

         PackageLoader fileInPackages: #('Blox' 'Browser').
         PackageLoader fileInPackage: 'Compiler'.

The second way is to use the gst-load script which is installed together with the virtual machine. For example, you can do:

gst-load Browser Blox Compiler

and gnu Smalltalk will automatically file in:

Then it will save the Smalltalk image, and finally exit.

gst-load supports several options:

-I
--image-file
Load the packages inside the given image.
-i
--rebuild-image
Build an image from scratch and load the package into it. Useful when the image specified with -I does not exist yet.
-q
--quiet
Hide the script's output.
-v
--verbose
Show which files are loaded, one by one.
-f
--force
If a package given on the command-line is already present, reload it. This does not apply to automatically selected prerequisites.
-t
--test
Run the package testsuite before installing, and exit with a failure if the tests fail. Currently, the testsuites are placed in the image together with the package, but this may change in future versions.
-n
--dry-run
Do not save the image after loading.
--start[=ARG]
Start the services identified by the package. If an argument is given, only one package can be specified on the command-line. If at least one package specifies a startup script, gst-load won't exit.

To provide support for this system, you have to give away with your gnu Smalltalk goodies a small file (usually called package.xml) which looks like this:

     <packages>
     <package>
       <name>BloxGTK</name>
       <namespace>BLOX</namespace>
       <directory>blox-gtk</directory>
     
       <!-- The prereq tag identifies packages that
            must be loaded before this one. -->
       <prereq>GTK</prereq>
     
       <!-- The provides tag identifies packages that
            need not be loaded once this one is. -->
       <provides>BLOX</provides>
     
       <!-- The filein tag identifies packages that
            compose this package and that should be loaded in the
            image in this order. -->
       <filein>BloxBasic.st</filein>
       <filein>BloxWidgets.st</filein>
       <filein>BloxText.st</filein>
       <filein>BloxExtend.st</filein>
       <filein>Blox.st</filein>
     
       <!-- The file tag identifies packages that
            compose this package's distribution. -->
       <file>Blox.st</file>
       <file>BloxBasic.st</file>
       <file>BloxWidgets.st</file>
       <file>BloxText.st</file>
       <file>BloxExtend.st</file>
     </package>
     </packages>

Other tags exist:

module
Loads a dynamic shared object and calls the gst_initModule function in it. Modules can register functions so that Smalltalk code can call them, and can interact with or manipulate Smalltalk objects. The Sockets package uses a module to provide a bridge to the socket functions.
library
Loads a dynamic shared object and registers the functions in it so that they can all be called from Smalltalk code. The GTK package registers the GTK+ library in this way, so that the bindings can use them.
callout
Instructs to load the package only if the C function whose name is within the tag is available to be called from Smalltalk code.
sunit
Specifies a testing script that gst-sunit (see SUnit) will run in order to test the package. If this is specified, the package should list SUnit among the prerequisites.
start
Specifies a Smalltalk script that gst-load and gst-remote will execute in order to start the execution of the service implemented in the package. Before executing the script, %1 is replaced with either nil or a String literal.
stop
Specifies a Smalltalk script that gst-remote will execute in order to shut down the service implemented in the package. Before executing the script, %1 is replaced with either nil or a String literal.
test
Specifies a subpackage that is only loaded by gst-sunit in order to test the package. The subpackage may include arbitrary tags (including file, filein and sunit) but not name. The SUnit package is implicitly made a prerequisite of the testing subpackage, and the default value of directory and namespace is the one given for the outer package.

To install your package, you only have to do

         gst-package path/to/package.xml

gst-package is a Smalltalk script which will create a .star archive in the current image directory, with the files specified in the file tags. By default the package is placed in the system-wide package directory; you can use the option --target-directory to create the .star file elsewhere.

Alternatively, gst-package can be used to create a skeleton GNU style source tree. This includes a configure.ac that will find the installation path of GNU Smalltalk, and a Makefile.am to support all the standard Makefile targets (including make install and make dist). To do so, go in the directory that is to become the top of the source tree and type.

         gst-package --prepare path1/package.xml path2/package.xml

In this case the generated configure script and Makefile will use more features of gst-package, which are yet to be documented. The gnu Smalltalk makefile similarly uses gst-package to install packages and to prepare the distribution tarballs.

The rest of this chapter discusses some of the packages provided with gnu Smalltalk.