Features of ups¶
Ups allows us to share the same build of a package with different users and projects.
At it's heart, ups simply provides a standard mechanism for setting environment variables and adding directories to paths. The implementation can be thought of as a simple database.
ups, cetbuildtools, and art¶
It is very important that any build of the art framework be self consistent at the binary level. We have to worry about compilers, compilation flags, and possible other options. For instance, if we build root with certain features enabled, we need to make sure we use that same build of root for all associated packages.
One could simply build everything from the ground up each time a change was required, but that is time consuming and wasteful of resources. For instance, a bug fix release of art will generally use exactly the same set of underlying packages as the previous. There is no reason to build these packages again, we simply need to use them again.
Relocatable ups allows us to keep all this straight.
Cetbuildtools was created to provide useful cmake macros and other tools. Some of these tools and macros deal with the information provided by ups. We also use the tools to create and install our builds as ups products.
We use 3 basic features of relocatable ups:
- Every package is installed without hard coded paths. Instead, paths are all relative. When you use ups to "setup" a package, then you will get a full path to the current installation.
- The installation directory tree is self contained. Common directories such as include and source are usually shared and installed directly under package/version. Each compiler/qualifier set will have a separate subdirectory under the package/version directory. See About Qualfiers for more information about qualifiers.
- These installations can be picked up and moved anywhere because the paths are relative. We build tarballs for package/version/qualifier combinations and provide them for distribution at http://scisoft.fnal.gov/
Variables we use¶
All variables begin with an uppercase translation of the package name, which we will designate at <PACKAGE>. For instance, if we setup gcc, <PACKAGE>_DIR would be GCC_DIR.
- <PACKAGE>_DIR - common directories, such as include and source.
- <PACKAGE>_FQ_DIR - flavor/qualifier specific directories, such as bin and lib.
- <PACKAGE>_VERSION - the package version in ups terms (vx_y_z)
- <PACKAGE>_LIB - the package lib directory
- <PACKAGE>_INC - the package header directory
- when appropriate, bin directories will be added to PATH
- when appropriate, lib directories will be added to LD_LIBRARY_PATH or DYLD_LIBRARY_PATH
- when appropriate, directories containing fcl files will be added to FHICL_FILE_PATH