Back to documentaton overview

Configuring buildmanager

Config files read by buildmanager

There are several configuration files for buildmanager that users or system managers may want to configure, and the configuration can be done in one of three places to affect any indivdual user:

The system-wide ${BUILDCONFIG_DIR}/lib/system.cfg
The cluster-wide ${BUILDCONFIG_DIR}/lib/ domainname .cfg
The users ${HOME}/.buildmanagerrc

These files are searched for in this order, and are sourced into the buildmanager program, which is an expect script, which means they are written in Tcl -- the Tool Command Language. Variables and procedures which are commonly defined in these files are examined in the following sections.

Making simple changes in your .buildmanagerrc

If you just want to turn on/off a particular host, do:

  set host_dat(do,bldlinux61)   1
  set host_dat(do,bldosf1v40d)  0

in your ~/.buildmanagerrc, and leave the rest alone. If you want to just add one alternate host do:

  set host_dat(LIST) "$host_dat(LIST) myhost"
  set host_dat(h2f,myhost)   IRIX+5
  set host_dat(do,myhost)    1

to change product roots, add a definition for proc "productroot" to your .buildmanagerrc as described in the next section.

Defining the product root

buildmanager believes it knows where the working copy of a given product for a given flavor is supposed to be. It determines this by calling the Tcl subroutine productroot with an argument of the flavor (or flavor and -q qualifiers). This subroutine should return a string giving the pathname to the directory involved. For example, consider the following definition in your domainname.cfg file:

proc productroot { flavor } {
    global product version env

    if { "$flavor" == "Linux+2" } {
        return "/scratch/${product}-${version}-${flavor}"
    }
    return "/usr/products/build-scratch/${product}-${version}-${flavor}"
}

This puts the working copy under /scratch for Linux systems, and under /usr/products/build-scratch otherwise. Note the use of the global variables product , version , and env , which are the product name from the main buildmanager window, the version string from the main buildmanager window, and the UNIX environment hashed array, respectively.

Defining the list of hosts

The list of hosts buildmanager uses at startup is defined somewhat in pieces in the config file,
all by setting entries in the host_dat hashed array. For each host you want to have buildmanager know about at startup, the following items are needed:

The host name should appear in the list value of host_dat(LIST)
1 or 0 should be the value of host_dat(do, hostname ) , which says if the host should initially have its entry checked on or off.
The host's flavor should be the value of host_dat(h2f, hostname ), which defines what Operating System string will be associated with that host

So, an example with two hosts, one flavor Linux+2, one flavor IRIX+5 would be:

set host_dat(LIST) {linuxhost irixhost}

set host_dat(do,linuxhost) 1
set host_dat(do,irixhost)  1

set host_dat(h2f,linuxhost) Linux+2
set host_dat(h2f,irixhost)  IRIX+5

Defining O.S. specific startup commands

The hash os_dat contains various information associated with each O.S. string flavor defined in host_dat. In particular, it includes os_dat(PLAT_COMMANDS, flavor ) , which are commands to run upon logging into machines of O.S. string flavor . Also, os_dat(PATH, flavor ) contains the initial value for the PATH environment variable that buildmanager will set upon logging into the system. There should also be an operating system list in os_dat(LIST). Setting these values looks like:

set os_dat(LIST)  {IRIX+5 Linux+2 SunOS+5}

set os_dat(PATH,Linux+2) "/bin:/sbin:/usr/bin:/usr/local/bin:/usr/X11R6/bin"
set os_dat(PATH,IRIX+5)  "/usr/X11/bin:/usr/bsd:/usr/ccs/bin:/usr/local/bin"

lappend os_dat(PLAT_COMMANDS,SunOS+5)     {setenv OPENWINHOME "/usr/openwin"}
set os_dat(PATH,SunOS+5) "/opt/SUNWspro/bin:/bin:/usr/bin:/usr/ccs/bin:/usr/ucb:/usr/openwin/bin:/usr/local/bin"

Changing the Commands menu

The commands menu is built from the array cmd_menu, which is a hashed array mapping from strings which will appear in the menu to internal buildmanager Tcl commands. It is reccomended you always include at least the following ones to be compatable with the buildmanager documentation:

array set cmd_menu {
    {cd}                {cmd_parallel  "cd %D"}
    {cvs export}        {cmd_taketurns "cd %d; cvs export -r %V -d %T %P" }
    {cvs checkout}      {cmd_parallel  "cd %d; cvs co -r %V -d %T -A %P" }
    {make build_n_test} {cmd_parallel "(cd %D; make build_n_test)"}
    {setup -q build?}   {cmd_parallel  "cd %D; setup -q 'build?' -r `pwd` -M ./ups -m %P.table %P"}
    {setup}             {cmd_parallel  "cd %D; setup  -r `pwd` -M ./ups -m %P.table %P"}
    {make declare}      {cmd_taketurns "(cd %D; make declare)"}
    {make all}          {cmd_parallel  "(cd %D; make all)"}
    {make test}         {cmd_parallel  "(cd %D; make test)"}
    {make clean}        {cmd_parallel  "(cd %D; make clean)"}
    {make kits}         {cmd_taketurns "(cd %D; make kits)"}
    {make local}        {cmd_taketurns "(cd %D; make local)"}
    {remove source}     {cmd_parallel  "cd %d; rm -rf %T"}
    {cvs update}        {cmd_parallel "(cd %D; cvs update -d)"}
    {cvs update -A}     {cmd_parallel "(cd %D; cvs update -A)"}
    {clear auto}        {clear_statepending}
    {interrupt}         {cmd_parallel  "\x003"}
    {exit}              {cmd_parallel  "exit"; after 5000 exit}
}

Note that the menu is generated by sorting the hash keys (otherwise they come out in no particular order)
so you may want to put leading numbers or something to make them come out in a given order.

You can modify these individual commands, or add more, by setting individual items in the
cmd_menu array in your config files as well, for example

set cmd_menu(check disk space) {cmd_parallel "df  %D"}

will add a "check disk space" item to the menu which will run "df" on all of the hosts.