art is used to build physics programs by loading physics algorithms, provided as plug-in modules. art is both used by and relies on other products in order to integrate into an experiment’s event-processing software architecture. A system using the art framework may be said to be comprise the following:
– a development environment for user-developed code
– a run-time environment in which compiled user-developed applications and libraries and other support files are combined with required third-party applications, libraries and other files to provide a usable system
Both of these environments will require access to third-party libraries compiled in a way that is compatible with the user code. The development environment additionally requires access to the header files describing the entities available for use in the third-party libraries.
The art Suite of Software
The art team provides separate tarballs containing:
- headers, compiled libraries and applications, and other supporting files; and
- source code
for the art suite, its dependencies down to and including a compiler, and a wide variety of other packages commonly required by experiments using the art framework. Binary packages are provided for a variety of platforms (see System Requirements for more details).
From the point of view of an experiment using the art framework, everything not developed by the experiment itself is an external package. Examples are:
- The packages comprising the art framework (the, “art suite”).
- Packages required by art such as Boost, ROOT and its dependencies.
- Packages required by the experiment such as Geant4, GENIE and others.
- The compiler(s) used to compile everything in a consistent and compatible way.
The Development Environment
The development environment is completely under the control of the experiment. Although Fermilab provides a CMake-based build system, MRB / cetbuildtools, its use is in no way necessary in order to use the art framework and other packages distributed by the art team. In order to use the art framework, the build system must be able to:
Find and use the correct compiler with compatible options to build experiment code as specified by the particular version and build variant of the art framework to be used.
Find the headers, libraries and other important files in each external package. As provided, packages built by the art team each have a simple setup procedure which defines or augments variables in the environment such as
DYLD_LIBRARY_PATH to make this easier for the build system.
Generate any plugins or ROOT dictionaries in the way that is required by the artframework.
Experiments have used the art framework successfully with build systems utilizing SCons, CMake, and SoftRelTools (a legacy HEP build system utilizing GNU Make).
The Run-time Environment
The runtime environment has only one constraint imposed on it by the art framework: it must be able to find applications (
PATH) and plugin or other shared libraries (
DYLD_LIBRARY_PATH) for all required packages from the art suite release set, including the compiler as specified by the particular version and build variant of the release set.
The art framework source code currently (early October 2014) contains C++ at the level of ISO C++ 2011 and recent releases may be used in development and runtime environments utilizing GCC 4.8.2 and GCC 4.9.1, which are shipped with release sets. Releases from approximately November 2014 onward will use ISO C++ 2014 features to improve the efficiency and maintainability of the code and therefore drop support for GCC 4.8.2. We intend in the relatively near future to ship the current LLVM/Clang compiler set and associated C++ standard library and support building the art release set with them. We are monitoring the Intel compiler suite, but as of version 15.0.0 it does not yet offer the level of language support that we require. In general, we start supporting a particular minor release series of GCC soon after the release of version X.Y.1.