Using glastpack for Code Development

Using glastpack for Code Development

Prerequisites	Creating a development area	Getting ready to use an area
Using an area	glastpack and gdb

Note: This page applies only to developers working on a Linux machine.

Prerequisites

Finding glastpack:

If using a SLAC public Linux machine, glastpack is located at:

/afs/slac.stanford.edu/g/glast/ground/scripts/glastpack.pl

Run the group cshrc which:

defines environment variables GLASTROOT and GROUPSCRIPTS

appends them to PATH

sets up CVS environment variables CVSROOT and CVS_RSH

sets up access to publicly-installed verison of CMT

sets up access to publicly-installed external libraries

If not on a SLAC Public machine:

Be sure you have completed all Desktop Installation (Developers): Linux procedures, then

Check out the latest tagged copy of glastpack from the CVS repository and put it in a directory included in your PATH.

bash$ cd /somewhere/writable
bash$ glastpack.pl create myDir
What this does for you is to make a file called CMTPATH in this directory. This way you can switch from one working area to another, using the glastpack.pl login and glastpack.pl logout commands to point to the correct one of these files at any given time.

Start using it

bash$ cd myDir; glastpack.pl login

(In more detail, glastpack.pl makes a soft link in your home directory, .cmtrc, to the correct CMTPATH file.)

Modify CMTPATH if necessary (otherwise only thing in CMTPATH will be the new playpen).

bash$ glastpack.pl add /path/to/somewhere

bash$ glastpack.pl remove /path/unwanted

Caution! When developing on Linux, if there are multiple paths in the CMTPATH, at run time the wrong version of a library can be picked up. Linux developers are encouraged to use one directory when building and running applications via CMT. If you desire to build against a pre-built release, it is suggested that you:

Copy the desired build into your development area.

Replace or override release packages as needed with new development versions.

Do cmt broadcast cmt config.

Then build the new packages.

Check out a package and everything it depends on

bash$ glastpack.pl rco topPackage version

For development one may specify HEAD for the version. As always, the latest matching tagged version of subsidiary packages will be checked. If any of these packages are also to be developed, you'll want the HEAD. You can get it by issuing the right type of cvs update, one that says to forget about sticky tags:

bash$ cd devPack/version
bash$ cvs update -A

Stop using an area

bash$ glastpack.pl logout

Caution! The logout command breaks the connection between .cmtrc in your home directory and the CMTPATH for the area. By default CMT uses .cmtrc in your home directory, if there is one, for the CMTPATH definition. If you don't issue a logout, future CMT commands will continue to use the area's CMTPATH, even if you logged off the computer and then logged back in.

Getting ready to use a previously-created area

Typically you only need to go through the above steps once for each tree of packages you want to work with. (One exception is the cvs update command to replace a tagged version of a package with the HEAD, something you might want to do at any time.) If you have already gone through the above steps in some previous login (i.e., computer login), all you need to do to pick up in a new session is issue the glastpack login again:

bash$ cd /somewhere/writable/myDir; glastpack.pl login

Using the area

Typical things to do will be to build a package (and packages it depends on if binaries are out of date) or run a test program

Building: bash$ glastpack.pl build aPackage dirTagVersion; Here dirTagVersion is the string appearing as part of the path to the package. For tagged packages this string will just be the tag. A package in development (HEAD version) still will have some tag-like string as part of its path; this is what you use. For example,
bash$ glastpack.pl build detModel v2r12
Running a program: bash$ glastpack.pl run packageName app; bash$ glastpack.pl run detModel test.exe

glastpack and gdb

Normally glastpack defines necessary environment variables only when you issue a command such as glastpack.pl build.. or glastpack.pl run... and only within the context of that command. As of August, 2002, there is no glastpack command to start up the debugger; at best such a thing would be awkward to use. Instead, one can start up the debugger as usual as long as necessary environment variables, including LD_LIBRARY_PATH, are defined. Just go to the cmt directory of the top package (e.g., Gleam) and, preferably from a bash shell, issue the setup command:

bash$ source setup.sh

Now your process has all the requisite definitions. Child processes will inherit them, as long as you don't reset anything (LD_LIBRARY_PATH is the most likely and most harmful to reset) in your .cshrc or .bashrc. This is crucial since gdb started from your terminal session (or gdb started from emacs started from your terminal session) is a child process. I haven't tried it, but it should also be possible to start up ddd this way.