Back to Trigger Home.

How to generate executables with L2 tagsets

What's new (Sept 25, 2002)

• Don't do setup fer, it brings in a bad version of perl. Sigh.
• Added a new section describing other tools I've written for managing L2 code.
• The need for unsetup perl has gone away, it seems, when Bill B. removed some old perl versions.
• After generating the tagset, the build.pl script will now ask you to write a quick comment. It will use either the editor specified in your $VISUAL environment variable, or pico if none is set.

How-to

• Start with the current default set of tags. For instance, at one point, the default set of tags was
  • v2_0_repoMar26, for l2code
  • v2_1_recesFix, for alpha
  • v2_1_repoMar26, for L2run
  This is what you will get as of April 8, 2002 you run the gui and don't select anything. To find out what the GUI defaults are, and what a given tagset corresponds to, you can use the scripts in ~wittich/bin on the online machines (do unsetup perl; set path=( /usr/bin $path) and setup TriggerDB first - the former gets rid of an annoying perl problem.):
  • dump_l2tagsets.pl, shows contents of L2 tagset table.
  • dump_guidefs.pl, shows contents of L2 tagset defaults table. The last line in this one is the current default for the gui.
  For example:

  b0dap30: >~wittich/bin/dump_l2tagsets.pl
  Enter data base password for wittich@cdfonprd: 
  Connected to wittich@cdfonprd.
   Tags  Alphatag         L2runTag        l2codeTag       N  Table     Ver User     Retired
  ------------------------------------------------------------
    1 v2_0_repoMar26      v2_0_repoMar26  v2_0_repoMar26  1  L2_TORTURE       4   WITTICH  NULL
    2 v2_0_repoMar26      v2_0_repoMar26  v2_0_repoMar26  1  PHYSICS_1_01     4   WITTICH  NULL
    3 v2_0_repoMar26      v2_0_repoMar26  v2_0_repoMar26  1  COSMICS_NOTRAC   3   WITTICH  NULL
    4 v2_0_repoMar26      v2_0_repoMar26  v2_0_repoMar26  1  MINIMUM_BIAS_1   6   WITTICH  NULL
    5 v2_0_repoMar26      v2_0_repoMar26  v2_0_repoMar26  1  COSMICS          6   WITTICH  NULL
    6 v2_1_recesFix       v2_1_recesFix   v2_0_repoMar26  1  PHYSICS_1_01     4   WITTICH  NULL
    7 v2_0_repoMar26      v2_0_repoMar26  v2_0_repoMar26  1  SUMET5           1   WITTICH  NULL
    8 v2_0_repoMar26      v2_0_repoMar26  v2_0_repoMar26  1  PHYSICS_TEST_1   14  LUCIANO  NULL
    9 v2_0_repoMar26      v2_0_repoMar26  v2_0_repoMar26  1  XFTTRACK_TEST_   2   WITTICH  NULL
   10 v2_1_recesFix       v2_1_recesFix   v2_0_repoMar26  1  XFTTRACK_TEST_   4   WITTICH  NULL
  b0dap30: >~wittich/bin/dump_guidefs.pl 
  Enter data base password for wittich@cdfonprd: 
  Connected to wittich@cdfonprd.
  Alphatag        L2runTag        l2codeTag       N
  ------------------------------------------------------------
  v2_0            v2_0            v2_0            1               CDFTRIG_PRD     
  v2_0_repoMar26  v2_0_repoMar26  v2_0_repoMar26  1               WITTICH         
  v2_1_recesFix   v2_1_recesFix   v2_0_repoMar26  1               WITTICH         
  	

• Check out a fresh release with these tags. We need to make sure that the files all compile with one another, so we will generate a release with all the relevant files in one place and then compile the program before we generate the tagset.

     % mkdir testrel; cd testrel; mkdir lib
     % cvs checkout -r v2_0_repoMar26 l2code 
     % cvs checkout -r v2_1_recesFix alpha 
     % cvs checkout -r v2_1_recesFix L2run
  	

• Edit or checkout the files you want to use.... We'll assume that you only want to modify one file here, run.cc.

    % emacs L2run/src/run.cc ....
  	

  - or -

    cvs checkout -r1.xx L2run/src/run.cc
  	

• You now need to get rid of the "Sticky tags" for the files that were changed. There are two ways to do this. The first is appropriate if your file is at the head of the repository, i.e., no one has changed it since your new modification, or the changes were minor and your new code can be merged in (use your judgment.).

    %  cvs update -A L2run/src/run.cc
  	

  for all files that you've changed. This will update the files to the head. You can see if the `sticky tags' are still there by doing

    % cvs status L2run/src/run.cc
  	

  If your files are not at the head, you should create a branch instead. This is done as follows.

  • Check out the versions of the code that you want to base your branch from. I.e., if you want to modify version v2_1 of the L2run package (and there is a later tag, e.g. v2_2 or many changes since then).

      % cvs checkout -r v2_1 L2run
                

  • Create a branch. This just changes the repository, but does nothing to your local files.

      % cvs rtag -b -r v2_1 v2_1a_branch L2run
    	    

    I think we should try to make the branch name (here, v2_1a_branch) be such that it is clearly a branch, e.g., if the base is v2_1, it could be something like v2_1a.
  • Switch to that branch. This tells the repo that all your commits from now on will be from that branch.

      % cvs update -r v2_1a_branch L2run
    	    

    To convince yourself that you ar now on that branch, you can use the command `cvs status: It should list the branch name in the `sticky tag' field.
  • You're now ready to continue on below. I would use a tag name below that contains the fact that this is a branch, such as v2_1a_ErrMonFix
  • In some cases, you want to merge the changes from a branch into your current revision. For instance, if you fix a bug on the head, you might want to propagate that same fix to the head of the repository. This is how to do that.

      % cvs update -j v7_0a_mergingBranchname File(s)
    	    

    Alternatively, you can just put in your fixes into the head by hand.
• Compile the code in question to make sure we can built an executable.

    % gmake -C alpha; gmake -C l2code; gmake -C L2run
  	

• When you're happy, commit any code you've changed, and tag the release. Ideally, I'd only tag the directory you modified or the packages which have a different collection of files than the default. This makes it easier to see what's new.

    % cvs commit -m "modifications to make this file more excellent" L2run/src/run.cc
    % cvs tag v2_1_myExcellentFix L2run
  	

• now, you can build a new tagset for a given physics table. You have two options

  1. Use the GUI

     In a new shell:

       % setup TriggerDBGui
       % triggerGui
         

     Select edit/view trigger table, and then choose the trigger table you want, and choose "Recompile L2 code". Choose the tagsets you want by selecting the `edit' button for L2 tagsets..

  2. Command-line script

     If you're a command-line kind of person, you can do it all from the shell. Again, in a new shell (taking note of the perl warnings):

       % setup TriggerDB 
       % ~wittich/bin/build.pl --help
         

     shows you all the options. You need

       --l2codetag v2_0_repoMar26
       --alphatag v2_0_repoMar26
       --l2runtag v2_0_myExcellentFix
       --triggertable PHYSICS_1_01
       --version 4
       --dbinfo wittich/mypasswd@cdfonprd
         

     can also do wittich@cdfonprd if you don't want to put your password on the command line, in which case you will get prompted for the information.

     ---

     The only required options are those that are different from the GUI defaults. It's a bit of an annoyingly long set of things. Other options are

       --num_alphas 1  <- currently unused
       --verbose
       --debug
       

     The last two send more and more output to standard output. Good for debugging. If your table doesn't build, run with these options before you send me a bug report; otherwise, I'll just have to do it.
  The build area is $TRIGGERDB_DIR/../triggerfiles/build_area. You can find a log file for the final result here, and in case of failure, the build directory isn't deleted. In case of success, only the log file remains.

  The log file will have a name such as PHYSICS_1_01_v-4_666_0.log during compilation, and L2_123_PHYSICS_1_01_v-4.log on success. The (somewhat convoluted) meaning of this is table name and version number, userid (to prevent people from clashing in their compiles), and a monotonically increasing number for each time this particular job is attempted. On success, the username part is removed and the file is prepended with L2_##, where the hashes are the L2 tagset for this file.

New default tagsets, synchronizing with the head of the repository, and the like.

• When we think we have a new default tag set, someone has to update the GUI_DEFAULTS table so that all new tables generated will use the new code.
• This brings up a new thing we'll have to do: On occasion, we'll have to synchronize the code we use in production with the head of the repository. I propose when we do this, we change the major version number of the code tag. When we do something like my_excellent_fix, we bump the minor number.

Some Caveats

• Don't do cvs checkout after having done setup TriggerDB. The latter sets you up for anonymous access to the on-line cvs repo, which makes it really annoying to try to check in new code.

• Getting around perl problems

  You might have problems with perl. In particular, it might fail right away when you start the script or try to run the scripts in ~wittich/bin . This is something I'm trying to sort out. It seems that the built-in perl in /usr/bin works on most (if not all) the machines I've tried. If you have problems,the following steps I should cure them:
  • unsetup perl. Some packages do this (such as kerberos). They setup an ancient version of perl, too.
  • Make sure /usr/bin is in your path before /usr/local/bin.
    For tcsh or csh:

     
        % set path=( /usr/bin $path)
        

    `which perl' should now return /usr/bin/perl
  • For bash, sh, ksh and variants:

        % export PATH=/usr/bin:$PATH
        

Other Tools

• dump_l2tagsets.pl. Gives a list of all tagsets and the relevat CVS tags. This script is now somewhat outdated since Bill B. made a servlet that lists the tagsets; see link below (data base query for ...). This shows the comment field, too, which Bill currently doesn't.
• dump_guidefs.pl. Shows the list of entries that are the default used by the GUI. The current default is the last entry in this table.
• recreate_tagset.pl XX, where XX is a tagset number. Builds a source tree ready for compiling, based on the tagset XX given on the command line. The tagset will be in the directory testdir_XX.
• insert_def.pl. Edit this script to update the GUI defs.

Links

• The CVS home, with a copy of the documentation on-line.
• A short CVS reference from CERN.
• The repository for the on-line code.
• Data base query for a list of Level 2 tagsets