Page History
...
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_RELEASE
are accepted. The first step is to find out which release to use using the following order:
- if the first parameter to the script names a valid release (present in
$SIT_RELDIR
...
- ) the environment will be set to this release (no test-release)
- otherwise, if it is
...
- a path to a test release (a directory that contains .sit_release) it uses this path and the base release (read from .sit_release)
- otherwise, if the current working directory (cwd) contains .sit_release
...
- the cwd is used as test release and the environment is set as in the previous step
- otherwise if
$HOME/SIT_RELEASE
is present its content is used for the release name (must be a valid release present in$SIT_RELDIR
) - 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).
...