Next: 9 The Prerequisites System Up: BUILD SCRIPTS: A Version Previous: 7 The Build System
The versioning system uses an XML-formatted version set file to specify
both package version information and package home directory definition
in the shell environment. An example file is shown in
Fig. ![[*]](crossref.png)
.
There is only one type of element, the package. Attributes are:
As we saw in Section ,
environment setting via gluex_env.(c)sh is sensitive to the
definition of the package home variables. In
Section , we saw that the package
makefiles are sensitive to either the version-defining environment
variables or the URL-defining environment variables, using them to choose the
version of code to build. The version set file can be used to define both
classes of variables. In this way it can be used to both build a
consistent set of packages and to set-up the environment to use the
build. Executing
$BUILD_SCRIPTS/version.pl version_1.7.xml
where for the purposes of this example version_1.7.xml is the
file shown in Fig. and GLUEX_TOP is
/home/gluex/gluex_top, creates the output shown in
Fig. .
Since you would want these commands applied to the current shell level, in practice you use
eval `$BUILD_SCRIPTS/version.pl version_1.7.xml`
Following this step, one normally would invoke gluex_env.(c)sh
to complete the set-up of the environment.
In this example, the variable definitions come (mostly) in pairs, a
version variable and a home directory variable. The version variable
affects only the build process since the corresponding package
makefile keys off it (see
Section ). The home directory variable
affects the build as well in that it tells the package makefile where
to find any prerequisite packages and in addition it affects use of a
build via its effect on path variables.
Finally, the script gluex_env_version.(c)sh combines use of
version.pl and gluex_env.(c)sh to more conveniently set
up the environment. We have already seen an example of its use in
Fig. . The script uses version.pl as
shown above to set the stage for an invocation of gluex_env.(c)sh.
We saw in Section that a URL variable
can be used to instructed the package makefiles to get the source code
from a version control repository rather downloading a tarball. The
url attribute in the package element calls out the value of the
URL to use directly. In a particular package element, either the
version attribute or the url attribute should
appear; if both appear then the version attribute will
be used (i. e., tarball).
If the url attribute is used, each package makefile
will interpret the URL as is appropriate for that package, either as a
Subversion repository or a Git repository; there can be only one
answer and it is coded into the package makefile. For Git
repositories, the optional branch attribute controls which
branch is checked out. If it is absent, the master branch is
used. For example, to clone sim-recon and checkout the branch
test_stuff, use
<package name="sim-recon"
url="https://github.com/jeffersonlab/sim-recon"
branch="test_stuff"/>
This will cause the SIM_RECON_BRANCH variable to be set in
the environment. Similarly the hash attribute can be used to
specify the hash of the particular commit to be checked-out.
<package name="sim-recon"
url="https://github.com/jeffersonlab/sim-recon"
hash="22fe917"/>
Note that for Subversion repositories, the branch specification is encoded in the URL itself and the branch and hash attributes are ignored.
The dirtag attribute can be used to distinguish different builds of a package where the only difference between them is the version(s) of one or more prerequisite packages. The string used is arbitrary. A directory tag can be attached to either a source directory made from a tarball or one from a source code repository. The tag name is appended after a caret symbol (ˆ), for example,
<package name="hdds" version="3.3" dirtag="xerces_test"\>in a version set file would cause version.pl to add an additional variable to the environment:
setenv HDDS_DIRTAG xerces_testand Makefile_hdds would then produce a directory named hdds-3.3ˆxerces_test, with source code obtained from the standard tarball, hdds-3.3-src.tar.gz in this case.
The corresponding home directory variable will also reflect the directory tag, of course.
There are a lot possible meanings for the directory tag. It could mark different combinations of prerequisites as well as designating packages where the source code does not come from a standard source (tarball or repository). Because of the large number of possibilities, the form of the tag string is left to the user; no assumption is made about it meaning.
Often one wants to use a build of a specific package that lies outside of the standard directory structure. This can be put into the environment by setting the home attribute of the corresponding package element. For example
The public version set files are stored in a GitHub repository, JeffersonLab/halld_versions, available at
At JLab the repository is checked out in
The names of the files are of two main types, (1) version sets that correspond to a periodic package update release and (2) version sets that correspond to a “launch” over GlueX data.