Difference between revisions of "HOWTO use a pre-built release"
(→Set your HALLD environment variables) |
|||
(9 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
=Find a compatible version= | =Find a compatible version= | ||
− | First determine your identifying tag. The | + | First determine your identifying tag (ID tag). The ID tag contains the operating system, the architecture, and the version of gcc you are using. To do this get a version of the script <code>osrelease.pl</code> and execute it. For example: |
svn co https://halldsvn.jlab.org/repos/trunk/scripts/build_scripts | svn co https://halldsvn.jlab.org/repos/trunk/scripts/build_scripts | ||
Line 17: | Line 17: | ||
or if you are on the JLab CUE: | or if you are on the JLab CUE: | ||
− | > /group/halld/Software/ | + | > /group/halld/Software/builds/build_scripts/prod/osrelease.pl |
Linux_RHEL5-i686-gcc4.1.2 | Linux_RHEL5-i686-gcc4.1.2 | ||
− | This tells you the | + | This tells you the ID tag for the build you want (in the last case <code>Linux_RHEL5-i686-gcc4.1.2</code>). If the build in question is built for your machine, it will contain a directory with this name in the <code>bin</code> and <code>lib</code> directories. |
+ | |||
+ | On the JLab CUE, these versions are built in the directory <code>/group/halld/Software/builds/sim-recon</code>. | ||
+ | |||
+ | Finally, you will want to set the BMS_OSNAME environment variable to the value of the ID tag. For example (assuming that osrelease.pl is in your path), | ||
+ | <pre> | ||
+ | setenv BMS_OSNAME `osrelease.pl` | ||
+ | </pre> | ||
=Set your HALLD environment variables= | =Set your HALLD environment variables= | ||
− | + | <ol> | |
− | + | <li> Set <code>HALLD_HOME</code> to point to the sim-recon root directory (the one that contains src, lib, bin, and include). For example, on the JLab CUE you might say | |
+ | <pre> | ||
+ | setenv HALLD_HOME /group/halld/Software/builds/sim-recon/sim-recon-2010-03-29 | ||
+ | </pre> | ||
+ | </li> | ||
+ | <li>Set <code>HALLD_MY</code> to a directory of your choice, one for which you have write privileges. For example, | ||
+ | <pre> | ||
+ | setenv HALLD_MY /home/myusername/halld_my | ||
+ | </pre> | ||
+ | </li> | ||
+ | </ol> | ||
+ | |||
+ | When you create a version of a library with your own code, it gets installed into $HALLD_MY/lib/$BMS_OSNAME always (and under $HALLD_HOME). In this way private code is kept separate from the public pre-built code and each user can have their own mix of private libraries in their $HALLD_MY directory. | ||
+ | |||
+ | In addition when the make scheme searches for libraries when linking, it will look first under $HALLD_MY/lib/$BMS_OSNAME and then in $HALLD_HOME/lib/$BMS_OSNAME. This way private code will get linked in preferentially over the public version. | ||
+ | |||
+ | Note that there are cases when you may want to ignore the stuff in HALLD_MY. One common example is when you want to do a complete build of sim-recon. See the [[Getting_started_with_GlueX_Software#COMPILING_THE_CODE|description of the LOCAL_HALLD_HOME variable]] for instructions on how to do this. | ||
+ | |||
+ | =Build a binary using a private library= | ||
+ | |||
+ | With these steps in place, here is an example of building a private version of hd_ana using custom modification to the BCAL library: | ||
+ | <pre> | ||
+ | # checkout the BCAL code | ||
+ | svn checkout https://halldsvn.jlab.org/repos/trunk/sim-recon/src/libraries/BCAL | ||
+ | # go into the BCAL directory | ||
+ | cd BCAL | ||
+ | # .....edit some files to modify BCAL reconstruction...... | ||
+ | # make the private library | ||
+ | make | ||
+ | # go back to where you started | ||
+ | cd .. | ||
+ | # checkout the hd_ana code | ||
+ | svn checkout https://halldsvn.jlab.org/repos/trunk/sim-recon/src/programs/Analysis/hd_ana | ||
+ | # go into the hd_ana directory | ||
+ | cd hd_ana | ||
+ | # make the private binary | ||
+ | make | ||
+ | </pre> | ||
+ | |||
+ | As mentioned above, the library will appear as $HALLD_MY/lib/$BMS_OSNAME/libBCAL.a and the binary will use it. The binary itself will appear as $HALLD_MY/bin/$BMS_OSNAME/hd_ana, again avoiding interference with the version of hd_ana present in the public build. |
Latest revision as of 10:42, 23 April 2014
If you have access to a pre-built version of the GlueX, you can use it without having to check out and build the entire set of sources.
Find a compatible version
First determine your identifying tag (ID tag). The ID tag contains the operating system, the architecture, and the version of gcc you are using. To do this get a version of the script osrelease.pl
and execute it. For example:
svn co https://halldsvn.jlab.org/repos/trunk/scripts/build_scripts A build_scripts/clhep_env.csh ... A build_scripts/osrelease.pl ... A build_scripts/Makefile_cernlib U build_scripts > build_scripts/osrelease.pl Linux_Fedora12-i686-gcc4.4.3
or if you are on the JLab CUE:
> /group/halld/Software/builds/build_scripts/prod/osrelease.pl Linux_RHEL5-i686-gcc4.1.2
This tells you the ID tag for the build you want (in the last case Linux_RHEL5-i686-gcc4.1.2
). If the build in question is built for your machine, it will contain a directory with this name in the bin
and lib
directories.
On the JLab CUE, these versions are built in the directory /group/halld/Software/builds/sim-recon
.
Finally, you will want to set the BMS_OSNAME environment variable to the value of the ID tag. For example (assuming that osrelease.pl is in your path),
setenv BMS_OSNAME `osrelease.pl`
Set your HALLD environment variables
- Set
HALLD_HOME
to point to the sim-recon root directory (the one that contains src, lib, bin, and include). For example, on the JLab CUE you might saysetenv HALLD_HOME /group/halld/Software/builds/sim-recon/sim-recon-2010-03-29
- Set
HALLD_MY
to a directory of your choice, one for which you have write privileges. For example,setenv HALLD_MY /home/myusername/halld_my
When you create a version of a library with your own code, it gets installed into $HALLD_MY/lib/$BMS_OSNAME always (and under $HALLD_HOME). In this way private code is kept separate from the public pre-built code and each user can have their own mix of private libraries in their $HALLD_MY directory.
In addition when the make scheme searches for libraries when linking, it will look first under $HALLD_MY/lib/$BMS_OSNAME and then in $HALLD_HOME/lib/$BMS_OSNAME. This way private code will get linked in preferentially over the public version.
Note that there are cases when you may want to ignore the stuff in HALLD_MY. One common example is when you want to do a complete build of sim-recon. See the description of the LOCAL_HALLD_HOME variable for instructions on how to do this.
Build a binary using a private library
With these steps in place, here is an example of building a private version of hd_ana using custom modification to the BCAL library:
# checkout the BCAL code svn checkout https://halldsvn.jlab.org/repos/trunk/sim-recon/src/libraries/BCAL # go into the BCAL directory cd BCAL # .....edit some files to modify BCAL reconstruction...... # make the private library make # go back to where you started cd .. # checkout the hd_ana code svn checkout https://halldsvn.jlab.org/repos/trunk/sim-recon/src/programs/Analysis/hd_ana # go into the hd_ana directory cd hd_ana # make the private binary make
As mentioned above, the library will appear as $HALLD_MY/lib/$BMS_OSNAME/libBCAL.a and the binary will use it. The binary itself will appear as $HALLD_MY/bin/$BMS_OSNAME/hd_ana, again avoiding interference with the version of hd_ana present in the public build.