Hacker's guide: Working in the build tree

Developing within the main source tree

How do I work within the tarball's build tree? How do I test it?

If you're making extensive changes to the system, it can be convenient to work directly on the system's source code tarball rather than using class extension as described above. One way of going about this is to configure it to install into a subdirectory of your working directory:

$ tar -zxvf smalltalk-2.95h.tar.gz
$ cd smalltalk-2.95h
$ ./configure --prefix=`pwd`/dist
$ make
$ make install

After this initial time-consuming configuration, compilation and installation, a local copy of gst is available in ./dist/bin/gst. You can now edit files in the source tree (not the ./dist directory!), and test your changes by running

$ make install
$ ./dist/bin/gst testcase.st

Each time you edit a file, you will need to rerun make install to publish your change to your experimental local installation.

How do I do the above without the install step?

You can run gst in the source or build tree without installing. Many changes can be made without running a full make. In particular, you can file in changed Smalltalk files if you are in the right namespace. Here is a short guide to changing files in different places:


Just file it in, making sure you are in the Smalltalk namespace. To incorporate the changes in an image, run make gst.im; alternatively,a script such as this will run GNU Smalltalk while loading modified kernel files automatically:

#! /bin/sh

# path to the build tree.
# path to the kernel/ directory under the source tree.
ulimit -d 175000
ulimit -m 175000
ulimit -v 400000
exec $image/gst -I $image/gst.im --maybe-rebuild-image \
    --kernel-dir=$kernel -g "$@"

The ulimit -v needs may be different on your system. Mine is about 60M over what gst uses after my first file load. I use the ulimits to stop runaway allocation; you can leave them out if you don't want that or you don't know what memory limits you can live with.


Switch to the right namespace (mentioned in a nearby package.xml) and file it in. It won't be incorporated automatically when you restart gst; you must run make (for example make NCurses.star to regenerate the .star file containing it.


These are C files, and changes can't be activated unless you rerun make and restart.

How do I debug changes to the C code for the distributed packages?

Some packages are split in two halves, one written in C and one written in Smalltalk. If the bug is in the C code, the only option is to develop in the source tree. To activate changes in the C code, just remake the .star file as indicated above.

An additional care is to run the tests/gst in the build tree, instead of ./gst. This will make sure that the modules' C code is loaded from the build tree rather than from a preexisting installation.

Syndicate content

User login