Code development on cluck and the grunts is the SSI group's main server, and is the only one of our machines on the public FNAL network.
grunt1 through grunt5 are the SSI group's worker nodes; they are only on a private network, and are only accessible through cluck.

Cluck is currently running Scientific Linux Fermi (SLF) version 6; the grunts (grunt1, 2, 3, 4, and 5) are running SLF5.
The home directories on the grunts are physically on a disk connecting to cluck, available at /mnt/disk1/grunt/home/<username>.

These instructions are brief guidelines. They cannot cover all complexities.

First setup of your environment

Home directories on cluck and the grunts are backed up. Because backup space is at a premium, it is best to keep source code under your home directory but to keep built products on either shared or node-local scratch space. On each grunt node, you have node-local scratch space at /scratch/<username>.

Using cetbuildtools, you will always be doing "out of source" builds -- that is, the directory in which you build your software will not be the directory in which the source code resides. Recommended practice is to
  1. check code out from the relevant repository into a directory under your "grunt home" directory. This must be done from cluck, because cluck is the only machine on the public network
  2. create a directory under your node-local scratch directory in which to build the product you have checked out.

Checking out source code

All of our git repositories hosted on cdcvs using the same naming scheme for the URLs. To clone the git repository for a project named X, use the following command:

git clone ssh://

This will create a directory named X in your current working directory.

Creating a build directory

Recommended practice to create the build directory for a project named X is:

mkdir /scratch/<username>/build-X
cd /scratch/<username>/build-X
source <path-to-where-you-cloned-the-X-repository>/ups/setup_for_development -d <qual>

This will setuo a debug build (the meaning of -d; your other choice is -p for an optimized profiling build); <qual> should be replaced by the qualifiers of the project in question for the build you're interested in. You can look in the product's setup_for_development file to find the options; the one labeled as the default is most often the right choice.

Building code and running tests

While in the build directory, use the buildtool command to build the software:

buildtool -j 20

will run cmake, then run make, using up to 20 processes. Try buildtool --help to get complete instructions on the use of buildtool.
Also see the buildtool script.

Dealing with product dependencies

Product dependencies are typically established when the code package is first written.

  • If the version of a dependent product changes, you must exit <path-to-where-you-cloned-the-X-repository>/ups/product_deps. This is the only required change, but you may also wish to update the minimum allowed version.

Using git

You can only access public network resources from cluck, so all git commands that work with the central repository (pull, push) must be run from cluck. You can do commits from the grunts. However, we've had best success when doing all git commands from cluck, because of the sometimes annoying delays involved with NFS syncing of the shared filesystems.