Each of the packages have their own native build system and each build system has its own set of details that have to be understood. In addition, the technology used to do the build varies from system to system. It may be make, imake, cmake, SCons, or something else. The BUILD SCRIPTS system makes a choice of build options for each package so that the user need not master these details.
The BUILD SCRIPTS build system is implemented in GNU Make. These makefiles invoke the native package-specific build system. The top-level makefile builds packages into the standard directory structure described in Section 4. It in turn uses a ``package makefile'' for each package (e. g., Makefile_jana, Makefile_sim-recon). Invoking make with a package makefile will build that package with the home directory placed in the current working directory. In other words, the package makefiles have no knowledge of the directory structure within which they are used; they just build locally. Only the top-level makefile knows about the directory structure.
Complete builds are orchestrated by Makefile_all. The highest-level targets of Makefile_all, shown with their dependencies are:
all: gluex_pass2 gluex_pass1: xerces_build lapack_build cernlib_build root_build \ geant4_build evio_build sqlite_build sqlitecpp_build \ rcdb_build ccdb_build gluex_pass2: gluex_pass1 jana_build hdds_build amptools_build \ hepmc_build photos_build evtgen_build halld_recon_build \ halld_sim_build hd_utilities_build hdgeant4_build \ gluex_root_analysis_build mcwrapper_build
The all target builds all officially supported packages. These are broken into two sets, gluex_pass1 and gluex_pass2 to solve the issue of packages that can only be set-up after they are built. This is a problem when starting from scratch. In that case the build must proceed in four steps.
make -f $BUILD_SCRIPTS/Makefile_all gluex_pass1
make -f $BUILD_SCRIPTS/Makefile_all gluex_pass2
Makefile_all should always be invoked from the $GLUEX_TOP directory.
If you would like the build to proceed in parallel (for those packages that support parallel builds), set an environment variable (eight threads in this example):
export NTHREADS=8or set the variable on the make commmand line. For example:
make -f $BUILD_SCRIPTS/Makefile_all gluex_pass2 NTHREADS=8
Each of the individual package targets (e. g., evio_build and hdds_build) use the corresponding package makefile. Directories are created and the package makes are executed in way that gives the directory structure described in Section 4. To do this, the package container directory is created if it does not exist and the requested package makefile is invoked from within the package container directory.
Of course, each individual package build target can be invoked directly. More on this in Section 7.3
The target cernlib_debug is non-standard. If this target is invoked, it well create a separate container directory cernlib_debug for the debug versions. Also it does not have its own package makefile, rather on 64-bit machines, it invokes Makefile_cernlib_Vogt with command line options that cause appropriate debug compiler flags to be used.
To use the resulting debug version of CERNLIB, the CERN variable must be set to point to the cernlib_debug directory, either explicitly as an environment variable (as described in Section 6.2.1 or by using the home attribute in the package element of a version set file (as described in Section 8.
Each of the package makefiles is sensitive to environment variables that control which version of the package to build. The makefiles themselves take care of obtaining the source code. In general, there are two ways to get the code: downloading a tarball or checking the code out from a version control repository, although the later option is not available for all packages.
Each packages respects a version-specifying environment variable. Here is an example of how they might be set in the C-shell:
setenv JANA_VERSION 0.7.2 setenv SIM_RECON_VERSION 1.2.0 setenv HDDS_VERSION 3.2 setenv CERNLIB_VERSION 2005 setenv XERCES_C_VERSION 3.1.1 setenv CLHEP_VERSION 2.0.4.5 setenv ROOT_VERSION 5.34.26 setenv CCDB_VERSION 1.05 setenv RCDB_VERSION 0.00 setenv EVIO_VERSION 4.3.1
In each case there is standard system for distributing tarballs marked with the version name. Each package has different conventions, but the package makefiles have that knowledge of the appropriate convention coded in. Also, the name of home directory created depends on the name that appears in the tarball (with exceptions as mentioned in Section 8.4. Note that the version variable can be set on the make command line as well.
Some packages can be checked out from a Subversion or Git repository. If that is the desired source of the code, the version variable should not be set. Instead a URL variable should be used to specify the location of the repository. For example:
setenv HDDS_URL https://github.com/jeffersonlab/hdds
will cause the HDDS package makefile to check out the master branch of the HDDS Git repository at GitHub. The names of the variables for other packages are JANA_URL (Subversion), CCDB_URL (Git), RCDB_URL (Git), and SIM_RECON_URL (Git) respectively.
For packages that use a Git repository, there are two additional variables that can be used to control the checkout. SIM_RECON_BRANCH is used to check-out a specific branch and SIM_RECON_HASH is used to check-out a specific commit of sim-recon. If one is set, the other should not be. There are analogous variables for CCDB, RCDB, and HDDS.
For the sim-recon package, there is a variable, SIM_RECON_SCONS_OPTIONS that can be defined, either in the shell environment on on the make command line, that will supply optional arguments to the scons command invoked by make. For example,
make -f $BUILD_SCRIPTS/Makefile_sim-recon \ SIM_RECON_SCONS_OPTIONS='SHOWBUILDS=1'will cause SCons to show the compiler commands explicitly.
The LAPACK and BLAS libraries are needed by CERNLIB. They are downloaded and build automatically, but rather than being installed in their own home directory, The ``install'' target of Makefile_lapack adds them to the lib directory of your CERNLIB build.
There are two ways:
After setting the desired values of the version environment variables and/or the URL environment variables (see Section 7.2 you can invoke Makefile_all with the target(s) needed or with a high-level target like gluex,
cd $GLUEX_TOP make -f $BUILD_SCRIPTS/Makefile_all gluexIf some of the versions of individual packages requested already exist, then make will do the usual thing: try to remake them and find that there is nothing to do.
Since the individual package makefiles build in the local directory, they can be used directly by going to the appropriate container directory. For example,
cd $GLUEX_TOP/sim-recon make -f $BUILD_SCRIPTS/Makefile_sim-recon SIM_RECON_VERSION=1.4.0Note that in this example the version is specified on the make command line rather than through an environment variable. That is not necessary; it is an option supported by make and defining SIM_RECON_VERSION in the environment would work as well. Also note that doing the build in the sim-recon container directory is not necessary for the build to succeed; any directory will work. In this example however we are adding to an existing standard directory structure so we cd to the standard directory.