Introduction

Below is some more detailed/advanced information about the offline build system. The offline build system is based on SCons. It is implemented as a set of scripts that import functionality from SConsTools (software developed internally). SConsTools introduces a package and release structure to support the build process.  The top level directory is for the release and contains the SConstruct file. Each package is in a sub-directory to the release.  Packages have a SConscript file. The structure of a release directory is explained in this page about Packages and Releases. SConsTools has a number of features including:

...

release/include
release/build
release/arch

You may also see

release/data
release/web

depending on the packages being built. These directories belong to the build system - you should never put anything in these directories. They will be rebuilt each time scons runs if need be.
In release/include you will find two links to the package include directories:

...

In the arch directory, you will find all the executables, scripts, libaries libraries (built as shared object libraries) and python modules for each package.

...

Most packages require no additional options beyond those in the default configuration. If a package requires additional build options, these can often be added by calling the standardSConscript() function in the SConscript file in the package directory. For instance, suppose a psana - Original Documentation user is developing a module in a package called MyPackage which needs to use functions from the Gnu Scientific Library. They would add the following line:

...

What if you want to make an external library available to all the packages in your release? It would be tedious to modify each new package you develop as in the section above. A better solution is to create an external package that interfaces to your the library. In your release directory, do the following:

...

# Do not delete following line, it must be present in 
# SConscript file for any SIT project
Import('*')

import os
from os.path import join as pjoin
from SConsTools.standardExternalPackage import standardExternalPackage
#
# For the standard external packages which contain includes, libraries, 
# and applications it is usually sufficient to call standardExternalPackage()
# giving some or all parameters.
#
PREFIX = os.path.expanduser('~username/mycode')
INCDIR = "include"
LIBDIR = "lib"
PKGLIBS = "mylib"
standardExternalPackage('MyCode', **locals())

This is the only file that need by in the MyCode package. After doing scons, any package in the release will be able to call functions in mycode by doing

...

INCDIR = os.path.expanduser('~username/mycode/include')
LIBDIR = os.path.expanduser('~username/mycode/lib')

It the external package has Many external packages are more than just a library. They have stand alone programs or tools to run, you . You can add these using the BINDIR parameter.  If an external package like MyCode were to in turn depend on another external package, that package could be defined in the same SConScript file and the DEPS parameter could be used when defining MyCode with standardExternalPackage. . An example of using these options can be seen in SConscript file for the hdf5 package. One can do

...

To upgrade the version of a release, see Typical Common development tasks.

Presentations

Below are slides from a talk given during the 2014 LCSL users meeting that covers the release/package structure of SConsTools, as well as how psana modules: Software_Development_Environment.pdf