Repository layout

The repository hosts a number of semi-independent toplevel trees: ... and so forth.

Anonymous repository access

Many of the instructions below assume that you have access to the Subversion repository. If you are having trouble with access, you can do an anonymous check out using the username "anonsvn" and the password "anonsvn". For example, to check out the admin tree, you would do the following:
 $ svn co --username anonsvn admin
If prompted, use "anonsvn" for the password. Following this step, you should be able to use admin/ to get the remaining source trees without trouble (see below). More information about the repository can be found at the SML/NJ GForge SCM page.

Web access to the repository

You can also browse the SML/NJ repositories using the ViewVC page for SML/NJ.

Directory layout

To compile and install SML/NJ, one needs to create a root directory (of arbitrary name, let's call it "root" for the purpose of this explanation) and then populate it with various sub-trees by checking out parts of this repository (and potentially other repositories). The default layout populates root with: Not all of these trees are always necessary.

Suppose we have added the following shell definitions to our environment:


By default, a tree T is obtained by performing

   svn co $smlnj/T/trunk T
There currently are two exceptions to this:
   svn co $smlnj/sml/trunk base
   svn co $gf/ml-lpt/trunk ml-lpt


We provide a small number of shell scripts to simplify the creation and maintenance of the default layout (or custom layouts that are variations of the default). These scripts are kept under Subversion control themselves (under $gf/admin). To use them, do:
   svn co $smlnj/admin admin
and put the name of the resulting admin directory (which could be located anywhere) into your shell's PATH.
To create the default layout, use root
This creates the root directory and populates it as described above. Without the optional argument, does not create a new root directory and treats the current directory "." as the root instead.

If some subtrees already exist, then will skip them. This is useful when working on a custom version of one or more of the subtrees while using default versions of the remaining subtrees. To establish such a setup, first create the root directory by hand, create your custom subtrees in whatever fashion desirable, and then run to pull in any remaining subtrees from the repository.

The script takes an optional flag --export (or simply -e). The use of this flag switches from svn checkout to svn export. This is useful for obtaining a copy of the sources without Subversion meta data.
To perform svn update on all subtrees, run
from within root. This command skips subtrees that are not under Subversion control. Like it takes the root directory as an optional argument, the default being the current directory.
Similarly, to perform svn stat on all subtrees, use Like the other two commands, takes the root directory as an optional argument.

Commits should be done on a per-tree basis "by hand" (i.e., using svn commit and its cousins).


The following are more detailed recipies for performing typical tasks.

I. Preparation

Assume that the path for your local smlnj development directory is the value of shell variable SMLDEV (e.g. in my case, SMLDEV=~/sml/Dev).
  1. define some shell variables
      $ export gf=
      $ export smlnj=$gf/smlnj
  2. In your $SMLDEV directory, create a directory gf
      $ cd $SMLDEV
      $ mkdir gf
  3. Go to gf and checkout the admin directory
      $ cd gf
      $ svn co $smlnj/admin
    This creates subdirectory gf/admin containing some shell scripts to automate checking out the full source code, checking status, etc.

  4. Add $SMLDEV/gf/admin to your shell PATH.

Of course, you could put this checkout somewhere else, such in your personal bin file, or in /usr/local/bin if you have permission. In this case, step 4 would not be necessary.

II. To check out a working copy of the trunk smlnj code and build the compiler

  1. Assuming you are in your development directory, create a working directory and check out the required top level subdirectories. This can be done in one step by giving a directory name as an argument, e.g.:
      $ smlnj
  2. Change to the new working directory and run the install script:
      $ cd smlnj
      $ config/
  3. If you do not have an existing ml-yacc in your PATH, then this may fail because of the order in which svn checks out certain ml-yacc source files. In this case, you can recover by executing
      $ touch ml-yacc/src/yacc.grm.sig ml-yacc/src/yacc.grm.sml
    to make these younger than ml-yacc/src/yacc.grm. This is a temporary problem until the build scripts are modified to take care of this.

III. To check out a private development branch

In this example, the branch is named primop-branch-3, and is based on the top-level repository directory $smlnj/sml.

  1. To check what branches exist under a top-level directory, like sml (= base), do
      $ svn list $smlnj/sml/branches/
  2. Create target directory, here called primop3, and change to it.
      $ mkdir primop3
      $ cd primop3
  3. In the target primop3 directory do
      $ svn co base
    or (given the definition of shell variable smlnj from part I above)
      $ svn co $smlnj/sml/branches/primop-branch-3 base
    This checks out the primop-branch-3 code for the sml directory, locally renamed as "base".

  4. Run to get the rest of the source code (assuming gf/admin has been added to the PATH)
  5. Run config/ to build the compiler.

David MacQueen and Matthias Blume
Last modified: Wed Feb 18 14:53:26 CST 2009