STAR   Computing Tutorials main page
Developing Offline Software
Offline computing tutorial Maintained by Kathy Turner and Torre Wenaus

Your working environment

The first issue is what working environment to use. Developers often -- too often -- use the 'dev' version of the software in order to have the latest versions of software available. If you really need to use dev, so be it, but read the discussion in the 'Software Releases' tutorial on the implications.

What do you get when you set >starpro (i.e. you setup to work in PRO) you may ask? Well... you get all the pointers set up to point to the correct version of the code on AFS. For example, > ls $STAR will point you to /afs/rhic/star/packages/SL99f (which is PRO right now). So now if you use $STAR to move around the directories under this, you will see all the tagged-PRO versions of the code. (NOTE! Remember that DEV doesn't get tagged and changes frequently). Then if you run root4star, you'll get the pro version of this exe. When you load all libraries in your root session, you will pick up all the pro versions of the libraries under $STAR. Also any macros that you use from the library will be picked up from under $STAR/macros. So see, you get quite a lot!!

Remember that there can be incompatibilities between versions so you cannot always read a data file made with a previous version for example.

You do not need to use dev in order to work with the latest versions of software. You can use new or pro and check out from the CVS repository the only the software components you need to be in dev. For example, if you need to work with the latest version of the TPC software StTrsMaker, but everything else is fine in pro, you can do the following (assumes your working directory is ~/workdir) 

  $ starpro
  $ cd ~/workdir
  $ cvs co StRoot/StTrsMaker
  $ root4star -b 'bfc.C(...)'
You are using the most up-to-date version of the TRS software, but you're in the pro environment for everything else.

If you want to check out a certain version of the code, it is not enough to do "starpro" and then "cvs co pams/tpc"!!! In this case, you will still get the dev ('CVS head') version of pams/tpc. To check out the pro version, you must find which SL99 version it is (for this example, it's SL99d). 

   Then you do 
     cvs co -r SL99d pams/tpc
  
    Of course, now you must still do 
       > starpro
    to make sure the the root4star version, macros and
    all other libraries you pick and and run are all from pro.
    Now you're totally in pro.

Of course the TPC software you're using from dev must be compatible with any software from pro that you're using (if you're working in pro). If, for example, you're using global software as well but the pro version of global is too out of date, you will have to check out and make pams/global as well.

If you are going to work in dev for whatever reason, you should be aware of the dev release policy! Basically any code changed and checked into CVS, will be checked out into dev and have the corresponding library rebuilt starting around 4pm EST each weekday (might take a few hours). So if the code has changed this day, you should check it out into your own area.

If you need to incorporate a change someone else just committed, just update your checked out copy... 

  $ cd ~/workdir/pams/tpc
  $ cvs update -A
  -- or to see what you're in for first --
  $ cvs -n update -A
where the latter just prints out what would happen if you did a cvs update without actually doing anything. The '-A' is needed if you originally checked out a particular tag as in the example above (it tells the update to override the tag). If you just did 'cvs co package' the '-A' has no effect.

See the tutorial on using CVS for more CVS info.