Versions Compared

Old Version 5

changes.mady.by.user Igor Gaponenko

Saved on

compared with

New Version 6

changes.mady.by.user Wilko Kroeger

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The above command needs to be executed every time when a user logs in, for . For convenience it should be added to the user's shell login script. In case of bash shell here is the line of code that should be placed into ~/.bashrc file:

...

  • SIT_ENV – defines the type of the SIT environment, can be default for regular setup or ana for analysis environment
  • SIT_ROOT – defines the location of the top directory for the PSDM software, usually /reg/g/psdm.
  • SIT_RELDIR – directory with regular PSDM release
  • SIT_RELEASE – the name of the software release to use, something like "current" or "ana-1.1.5"
  • SIT_ARCH – the name of the hardware/software architecture to use like x86_64-rhel5-gcc41-opt
  • SIT_DATA – list of directories where the data files reside. These are not regular XTC data files, bur but rather some additional data that software needs. Usually it includes ".<test-release>/data" and $SIT_RELDIR/$SIT_RELEASE/data (that is "data" directory in the releases) but can also be extended to include other locations.
  • SIT_REPOS – the locations of all "base" releases. Currently we only support single base release so this variable would look like $SIT_RELDIR/$SIT_RELEASE

...

  • PATH – should be extended to include .include <test-release>/arch/$SIT_ARCH/bin and and $SIT_RELDIR/$SIT_RELEASE/arch/$SIT_ARCH/bin
  • LD_LIBRARY_PATH – should be extended to include .include <test-release>/arch/$SIT_ARCH/lib and $SIT_RELDIR/$SIT_RELEASE/arch/$SIT_ARCH/lib
  • PYTHONPATH – should be extended to include .include <test-release>/arch/$SIT_ARCH/python and $SIT_RELDIR/$SIT_RELEASE/arch/$SIT_ARCH/python

The <test-release> place holder is the absolute path to test release which is a release that is based on a base release (in $SIT_RELEASE). All these variables could be set manually, but there is a single convenience script which can be sourced from the usersuser's shell which does all the tedious work.

...

Above scripts will define the alias sit_setup (sourcing the $SIT_ROOT/bin/sit_setup.{sh,csh}). This alias can be used to quickly change SIT_RELEASE, SIT_ARCH and all derived variables. To do that user calls sit_setup with change the environment variables to a new release or architecture. All path names to a release (test- and base-release) are using an absolute path. This means that changing a directory after running sit_setup will not change a release. When calling sit_setup zero or more parameters . Depending on the current working directory and parameters the script will change SIT_RELEASEare accepted. The first step is to find out which release to use using the following order:

  1. if the first parameter to the script names a valid release (present in $SIT_RELDIR

...

  1. ) the environment will be set to this release (no test-release)
  2. otherwise, if it is

...

  1. a path to a test release (a directory that contains .sit_release) it uses this path and the base release (read from .sit_release)
  2. otherwise, if the current working directory (cwd) contains .sit_release

...

  1. the cwd is used as test release and the environment is set as in the previous step
  2. otherwise if $HOME/SIT_RELEASE is present its content is used for the release name (must be a valid release present in $SIT_RELDIR)
  3. otherwise "current" or "ana-current" is used as the release name depending on environment type

Remaining The remaining parameters (that is all parameters except the first when if the first parameter is a release name or test-release path) are used to build build the SIT_ARCH value. SIT_ARCH is an ordered sequence of 4 values separated by dashes:

  • hardware architecture, such as i686, x86_64, etc.,
  • operating system brief name, such as rhel5, rhel6, rhel7, etc.,
  • compiler name and version, such as gcc41, gcc44, etc.,
  • debug/optimize/profile option, one of dbg, opt, prof.

The parameters to the sit_setup script can be used to specify one of the possible options for any of the four above items. If a parameter matches one of the possible options for the SIT_ARCH items, then that option is used in place of the default one. The simple example is:

...

Additionally sit_setup accepts keyword options which provide explicit values for different parts of the SIT_ARCH variable. This is useful when the script is used for the setup of the a completely new release, as in this case the script cannot always make a decision about such values as compiler name/version. The keyword options are:

  • -p processor – define processor type explicitly
  • -o os – define OS name explicitly
  • -c compiler – define compiler explicitly
  • -b build – define build type explicitly
  • -a name – define SIT_ARCH explicitly
  • -e env – overrides current value of SIT_ENV

The sit_setup script is executed on every logon and sets up the environment suitable for running PSDM software from the current production release. The script needs to be executed again if a user wants to switch to a different release or to use different build option (debug vs optimized builds).

...