Difference between revisions of "Deprecated: Setting Up the GlueX Environment"
(draft) |
|||
Line 1: | Line 1: | ||
− | We have two methods for setting up the environment for GlueX software. They are complementary; depending on what you want to do one will be more appropriate than the other. | + | We have two methods for setting up the environment for GlueX software. They are complementary; depending on what you want to do one will be more appropriate than the other. Let's call them "setenv" and "build_scripts". |
− | setenv | + | ==setenv== |
For every complete build of sim-recon, a setenv.csh and a setenv.sh file is produced. Sourcing the appropriate file will reproduce the GlueX-related environment that was used to build that version of sim-recon exactly. Find the files under the BMS_OSNAME directory (directory that looks like Linux_RHEL7-x86_64-gcc4.8.3 for example, pick the one appropriate for your platform) of HALLD_HOME. | For every complete build of sim-recon, a setenv.csh and a setenv.sh file is produced. Sourcing the appropriate file will reproduce the GlueX-related environment that was used to build that version of sim-recon exactly. Find the files under the BMS_OSNAME directory (directory that looks like Linux_RHEL7-x86_64-gcc4.8.3 for example, pick the one appropriate for your platform) of HALLD_HOME. | ||
Line 7: | Line 7: | ||
If you need custom settings of the environment, make a copy of the appropriate file and edit it. The file is nicely formatted and the changes you need are not hard to figure out. | If you need custom settings of the environment, make a copy of the appropriate file and edit it. The file is nicely formatted and the changes you need are not hard to figure out. | ||
− | Advantages: nothing to change, guaranteed consistency | + | * '''Advantages''': nothing to change, guaranteed consistency |
− | + | * '''Disadvantages''': customization by direct editing of script, need pre-existing successful build to start | |
− | build_scripts | + | ==build_scripts== |
There is a set of scripts to help you set-up your environment from scratch. Even if one is not starting from scratch, they can be used to set-up pre-existing sets of software. At JLab they are in /group/halld/Software/scripts/build_scripts . They can be checked out at https://halldsvn.jlab.org/repos/trunk/scripts/build_scripts. | There is a set of scripts to help you set-up your environment from scratch. Even if one is not starting from scratch, they can be used to set-up pre-existing sets of software. At JLab they are in /group/halld/Software/scripts/build_scripts . They can be checked out at https://halldsvn.jlab.org/repos/trunk/scripts/build_scripts. | ||
− | Default build at JLab | + | * '''Advantages''': do not need a pre-existing build, can customize configuration with re-writing scripts. |
+ | * '''Disadvantages''': more complicated, consistency of packages not guaranteed | ||
+ | |||
+ | ===Default build at JLab=== | ||
Sourcing the script gluex_env_jlab.(c)sh will set-up the default environment at JLab. | Sourcing the script gluex_env_jlab.(c)sh will set-up the default environment at JLab. | ||
− | Using a version.xml | + | ===Nightly build at JLab=== |
+ | |||
+ | Source the file gluex_env_nightly.(c)sh with a date argument in YYYY-MM-DD format, e. g. | ||
+ | |||
+ | <code>source $BUILD_SCRIPTS/gluex_env_nightly.csh 2015-07-15</code> | ||
+ | |||
+ | ===Using a version.xml=== | ||
− | If you are using the standard GlueX Version Managment System (GVMS) directory structure, you can use a version-specifying xml file to set up your environment. | + | If you are using the standard GlueX Version Managment System (GVMS) directory structure, you can use a version-specifying xml file to set up your environment. Version xml files are kept in /group/halld/www/halldweb/html/dist. |
− | + | # Define GLUEX_TOP and BUILD_SCRIPTS | |
− | + | # Identify a version.xml, e. g., /path/to/version.xml | |
− | + | # <code>source $BUILD_SCRIPTS/gluex_env_version.(c)sh /path/to/version.xml</code> | |
At JLab, there is a GLUEX_TOP for each supported platform in /group/halld/Software/builds. | At JLab, there is a GLUEX_TOP for each supported platform in /group/halld/Software/builds. | ||
− | Using version.xml and a custom build of sim-recon | + | ===Using version.xml and a custom build of sim-recon=== |
− | + | # Define GLUEX_TOP, BUILD_SCRIPTS | |
− | + | # Identify a version.xml, /path/to/version.xml | |
− | + | # <code>eval `$BUILD_SCRIPTS/version.pl $version_file`</code> | |
− | + | # <code>setenv HALLD_HOME /path/to/custom/sim-recon</code> (or <code>export HALLD_HOME=/path/to/custom/sim-recon</code>) | |
− | + | # <code>source $BUILD_SCRIPTS/gluex_env.(c)sh</code> |
Revision as of 16:30, 15 July 2015
We have two methods for setting up the environment for GlueX software. They are complementary; depending on what you want to do one will be more appropriate than the other. Let's call them "setenv" and "build_scripts".
Contents
setenv
For every complete build of sim-recon, a setenv.csh and a setenv.sh file is produced. Sourcing the appropriate file will reproduce the GlueX-related environment that was used to build that version of sim-recon exactly. Find the files under the BMS_OSNAME directory (directory that looks like Linux_RHEL7-x86_64-gcc4.8.3 for example, pick the one appropriate for your platform) of HALLD_HOME.
If you need custom settings of the environment, make a copy of the appropriate file and edit it. The file is nicely formatted and the changes you need are not hard to figure out.
- Advantages: nothing to change, guaranteed consistency
- Disadvantages: customization by direct editing of script, need pre-existing successful build to start
build_scripts
There is a set of scripts to help you set-up your environment from scratch. Even if one is not starting from scratch, they can be used to set-up pre-existing sets of software. At JLab they are in /group/halld/Software/scripts/build_scripts . They can be checked out at https://halldsvn.jlab.org/repos/trunk/scripts/build_scripts.
- Advantages: do not need a pre-existing build, can customize configuration with re-writing scripts.
- Disadvantages: more complicated, consistency of packages not guaranteed
Default build at JLab
Sourcing the script gluex_env_jlab.(c)sh will set-up the default environment at JLab.
Nightly build at JLab
Source the file gluex_env_nightly.(c)sh with a date argument in YYYY-MM-DD format, e. g.
source $BUILD_SCRIPTS/gluex_env_nightly.csh 2015-07-15
Using a version.xml
If you are using the standard GlueX Version Managment System (GVMS) directory structure, you can use a version-specifying xml file to set up your environment. Version xml files are kept in /group/halld/www/halldweb/html/dist.
- Define GLUEX_TOP and BUILD_SCRIPTS
- Identify a version.xml, e. g., /path/to/version.xml
-
source $BUILD_SCRIPTS/gluex_env_version.(c)sh /path/to/version.xml
At JLab, there is a GLUEX_TOP for each supported platform in /group/halld/Software/builds.
Using version.xml and a custom build of sim-recon
- Define GLUEX_TOP, BUILD_SCRIPTS
- Identify a version.xml, /path/to/version.xml
-
eval `$BUILD_SCRIPTS/version.pl $version_file`
-
setenv HALLD_HOME /path/to/custom/sim-recon
(orexport HALLD_HOME=/path/to/custom/sim-recon
) -
source $BUILD_SCRIPTS/gluex_env.(c)sh