Geant4Config.cmake CMake Config File

CMake Build System: Geant4Config.cmake

The Geant4Config.cmake file installed by Geant4 is designed to be used with CMake’s find_package command. When used, it sets several CMake variables and provides a mechanism for checking and activating optional features of Geant4. This allows you to use it in many ways in your CMake project to configure Geant4 for use by your application.

The most basic usage of Geant4Config.cmake in a CMakeLists.txt file is just to locate Geant4 with no requirements on its existence, version number or components

find_package(Geant4)

If Geant4 is an absolute requirement of the project, then you can use

find_package(Geant4 REQUIRED)

This will cause CMake to fail with an error should an install of Geant4 not be located. By default, CMake will look in several platform dependent locations for the Geant4Config.cmake file (see find_package for listings). If these are not sufficient to locate your install of Geant4, then the Geant4_DIR or CMAKE_PREFIX_PATH variables may be used. For example, if we have an install of Geant4 located in

+- opt/
   +- Geant4/
   +- lib/
      +- libG4global.so
      +- ...
      +- Geant4-G4VERSION/
         +- Geant4Config.cmake

then we could pass the argument -DGeant4_DIR=/opt/Geant4/lib/Geant4-G4VERSION (i.e. the directory holding Geant4Config.cmake) or -DCMAKE_PREFIX_PATH=/opt/Geant4 to cmake.

When an install of Geant4 is found, the module sets a sequence of CMake variables that can be used elsewhere in the project:

  • Geant4_FOUND

    Set to CMake Boolean true if an install of Geant4 was found.

  • Geant4_INCLUDE_DIRS

    Set to a list of directories containing headers needed by Geant4. May contain paths to third party headers if these appear in the public interface of Geant4.

  • Geant4_LIBRARIES

    Set to the list of libraries that need to be linked to an application using Geant4.

  • Geant4_DEFINITIONS

    The list of compile definitions needed to compile an application using Geant4. This is most typically used to correctly activate UI and Visualization drivers.

  • Geant4_CXX_FLAGS

    The compiler flags used to build this install of Geant4. Usually most important on Windows platforms.

  • Geant4_CXX_FLAGS_<CONFIG>

    The compiler flags recommended for compiling Geant4 and applications in mode CONFIG (e.g. Release, Debug, etc). Usually most important on Windows platforms.

  • Geant4_CXXSTD

    The C++ standard, e.g. “c++11” against which this install of Geant4 was compiled.

  • Geant4_TLS_MODEL

    The thread-local storage model, e.g. “initial-exec” against which this install of Geant4 was compiled. Only set if the install was compiled with multithreading support.

  • Geant4_USE_FILE

    A CMake script which can be included to handle certain CMake steps automatically. Most useful for very basic applications.

  • Geant4_builtin_clhep_FOUND

    A CMake Boolean which is set to true if this install of Geant4 was built using the internal CLHEP.

  • Geant4_system_clhep_ISGRANULAR

    A CMake Boolean which is set to true if this install of Geant4 was built using the system CLHEP and linked to the granular CLHEP libraries.

  • Geant4_builtin_expat_FOUND

    A CMake Boolean which is set to true if this install of Geant4 was built using the internal Expat.

  • Geant4_builtin_zlib_FOUND

    A CMake Boolean which is set to true if this install of Geant4 was built using the internal zlib.

  • Geant4_DATASETS

    A CMake list of the names of the physics datasets used by physics models in Geant4. It is provided to help iterate over the Geant4_DATASET_XXX_YYY variables documented below.

  • Geant4_DATASET_<NAME>_ENVVAR

    The name of the environment variable used by Geant4 to locate the dataset with name <NAME>.

  • Geant4_DATASET_<NAME>_PATH

    The absolute path to the dataset with name <NAME>. Note that the setting of this variable does not guarantee the existence of the dataset, and no checking of the path is performed. This checking is not provided because the action you take on non-existing data will be application dependent.

    You can access the Geant4_DATASET_XXX_YYY variables in a CMake script in the following way:

    find_package(Geant4_REQUIRED)                 # Find Geant4

foreach(dsname ${Geant4_DATASETS})            # Iterate over dataset names
  if(NOT EXISTS ${Geant4_DATASET_${dsname}_PATH})  # Check existence
    message(WARNING "${dsname} not located at ${Geant4_DATASET_${dsname}_PATH}")
  endif()
endforeach()

    A typical use case for these variables is to automatically set the dataset environment variables for your application without the use of setup scripts. This could typically be via a shell script wrapper around your application, or runtime configuration of the application environment via the relevant C/C++ API for your system.

The typical usage of find_package and these variables to configure a build requiring Geant4 is thus:

find_package(Geant4 REQUIRED)                       # Find Geant4
include_directories(${Geant4_INCLUDE_DIRS})         # Add -I type paths
add_definitions(${Geant4_DEFINITIONS})              # Add -D type defs
set(CMAKE_CXX_FLAGS ${Geant4_CXX_FLAGS})            # Optional

add_executable(myg4app myg4app.cc)                  # Compile application
target_link_libraries(myg4app ${Geant4_LIBRARIES})  # Link it to Geant4

Alternatively, the CMake script pointed to by Geant4_USE_FILE may be included:

find_package(Geant4 REQUIRED)                       # Find Geant4
include(${Geant4_USE_FILE})                         # Auto configure includes/flags

add_executable(myg4app myg4app.cc)                  # Compile application
target_link_libraries(myg4app ${Geant4_LIBRARIES})  # Link it to Geant4

When included, the Geant4_USE_FILE script performs the following actions:

  1. Adds the definitions in Geant4_DEFINITIONS to the global compile definitions.
  2. Appends the directories listed in Geant4_INCLUDE_DIRS to those the compiler uses for search for include paths, marking them as system include directories.
  3. Prepends Geant4_CXX_FLAGS to CMAKE_CXX_FLAGS, and similarly for the extra compiler flags for each build mode (Release, Debug etc).

This use file is very useful for basic applications, but if your use case requires finer control over compiler definitions, include paths and flags you should use the relevant Geant4_NAME variables directly.

A version number may be supplied to search for a Geant4 install greater than or equal to the supplied version, e.g.

find_package(Geant4 10.0 REQUIRED)

would make CMake search for a Geant4 install whose version number is greater than or equal to 10.0. An exact version number may also be specified:

find_package(Geant4 10.4.0 EXACT REQUIRED)

In both cases, CMake will fail with an error if a Geant4 install meeting these version requirements is not located.

Geant4 can be installed with many optional components, and the presence of these can also be required by passing extra “component” arguments. For example, to require that Geant4 is found and that it provides the Qt UI and visualization drivers, we can do

find_package(Geant4 REQUIRED qt)

In this case, if CMake finds a Geant4 install that does not support Qt, it will fail with an error. Multiple component arguments can be supplied, for example

find_package(Geant4 REQUIRED qt gdml)

requires that we find a Geant4 install that supports both Qt and GDML. If the components are found, any needed header paths, libraries and compile definitions required to use the component are appended to the variables Geant_INCLUDE_DIRS, Geant4_LIBRARIES and Geant4_DEFINITIONS respectively. Variables Geant4_<COMPONENTNAME>_FOUND are set to TRUE if component <COMPONENTNAME> is supported by the installation.

If you want to activate options only if they exist, you can use the pattern

find_package(Geant4 REQUIRED)
find_package(Geant4 QUIET COMPONENTS qt)

which will require CMake to locate a core install of Geant4, and then check for and activate Qt support if the install provides it, continuing without error otherwise. A key thing to note here is that you can call find_package multiple times to append configuration of components. If you use this pattern and need to check if a component was found, you can use the Geant4_<COMPONENTNAME>_FOUND variables described earlier to check the support.

The components which can be supplied to find_package for Geant4 are as follows:

  • static

    Geant4_static_FOUND is TRUE if the install of Geant4 provides static libraries.

    Use of this component forces the variable Geant4_LIBRARIES to contain static libraries, if they are available. It can therefore be used to force static linking if your application requires this, but note that this does not guarantee that static version of third party libraries will be used.

  • multithreaded

    Geant4_multithreaded_FOUND is TRUE if the install of Geant4 was built with multithreading support.

    Note that this only indicates availability of multithreading support and activates the required compiler definition to build a multithreaded Geant4 application. Multithreading in your application requires creation and usage of the appropriate C++ objects and interfaces as described in the Application Developers Guide.

  • usolids

Geant4_usolids_FOUND is TRUE if the install of Geant4 was built with VecGeom replacing the Geant4 solids.

Note that this only indicates that the replacement of Geant4 solids with VecGeom has taken place. Further information on the use of VecGeom in applications is provided in the Application Developers Guide.

  • gdml

    Geant4_gdml_FOUND is TRUE if the install of Geant4 was built with GDML support.

  • g3tog4

    Geant4_g3tog4_FOUND is TRUE if the install of Geant4 provides the G3ToG4 library. If so, the G3ToG4 library is added to Geant4_LIBRARIES.

  • freetype

    Geant4_freetype_FOUND is TRUE if the install of Geant4 was built with Freetype support.

  • hdf5

    Geant4_hdf5_FOUND is TRUE if the install of Geant4 was built with HDF5 support.

  • ui_tcsh

    Geant4_ui_tcsh_FOUND is TRUE if the install of Geant4 provides the TCsh command line User Interface. Using this component allows use of the TCsh command line interface in the linked application.

  • ui_win32

    Geant4_ui_win32_FOUND is TRUE if the install of Geant4 provides the Win32 command line User Interface. Using this component allows use of the Win32 command line interface in the linked application.

  • motif

    Geant4_motif_FOUND is TRUE if the install of Geant4 provides the Motif(Xm) User Interface and Visualization driver. Using this component allows use of the Motif User Interface and Visualization Driver in the linked application.

  • qt

    Geant4_qt_FOUND is TRUE if the install of Geant4 provides the Qt User Interface and Visualization driver. Using this component allows use of the Qt User Interface and Visualization Driver in the linked application.

  • wt

    Geant4_wt_FOUND is TRUE if the install of Geant4 provides the Wt Web User Interface and Visualization driver. Using this component allows use of the Wt User Interface and Visualization Driver in the linked application.

  • vis_dawn_network

    Geant4_vis_dawn_network_FOUND is TRUE if the install of Geant4 provides the Client/Server network interface to DAWN visualization. Using this component allows use of the Client/Server DAWN Visualization Driver in the linked application.

  • vis_vrml_network

    Geant4_vis_vrml_network_FOUND is TRUE if the install of Geant4 provides the Client/Server network interface to VRML visualization. Using this component allows use of the Client/Server VRML Visualization Driver in the linked application.

  • vis_raytracer_x11

    Geant4_vis_raytracer_x11_FOUND is TRUE if the install of Geant4 provides the X11 interface to the RayTracer Visualization driver. Using this component allows use of the RayTracer X11 Visualization Driver in the linked application.

  • vis_opengl_x11

    Geant4_vis_opengl_x11_FOUND is TRUE if the install of Geant4 provides the X11 interface to the OpenGL Visualization driver. Using this component allows use of the X11 OpenGL Visualization Driver in the linked application.

  • vis_opengl_win32

    Geant4_vis_opengl_win32_FOUND is TRUE if the install of Geant4 provides the Win32 interface to the OpenGL Visualization driver. Using this component allows use of the Win32 OpenGL Visualization Driver in the linked application.

  • vis_openinventor

    Geant4_vis_openinventor_FOUND is TRUE if the install of Geant4 provides the OpenInventor Visualization driver. Using this component allows use of the OpenInventor Visualization Driver in the linked application.

  • ui_all

    Activates all available UI drivers. Does not set any variables, and never causes CMake to fail.

  • vis_all

    Activates all available Visualization drivers. Does not set any variables, and never causes CMake to fail.

Please note that whilst the above aims to give a complete summary of the functionality of Geant4Config.cmake, it only gives a sampling of the ways in which you may use it, and other CMake functionality, to configure your application. We also welcome feedback, suggestions for improvement and bug reports on Geant4Config.cmake.

Going further with CMake

The preceding sections show the minimal CMake scripting required to configure, build and install an application linking against the Geant4 libraries. If your project requires more advanced configuration, CMake provides tools such as compiler/platform identification and location of additional libraries/executables to link to/use. As this document is specific to Geant4, we do not cover more advanced usage of CMake and recommend that you consult the online manuals and tutorials supplied by Kitware.

In particular, for the common use case of finding and using an external software package, see the documentation of the find_package command, overview of CMake’s package location functionality, and the list of packages CMake knows about out of the box. Location and use of a required package works exactly as we have illustrated for Geant4. Simply add the required find_package call to your CMake script, and use the supplied variables or targets for headers paths and library linking, e.g.

find_package(Foo 1.2 REQUIRED)        # Find "Foo" of at least version 1.2
find_package(Bar 3.4 EXACT REQUIRED)  # Find "Bar" at exactly version 3.4

include_directories(${Foo_INCLUDE_DIRS}) # Foo's setup supplies a header path

add_library(MyLibrary SHARED MyLibrary.cc) # Define our library
target_link_libraries(MyLibrary            # Link it
  ${Foo_LIBRARIES}                         # Foo's setup supplies a library path
  Bar::Bar                                 # Bar's setup supplies an "IMPORTED" target
  )                                        # which sets header and library paths automatically

You should consult the documentation of the packages your project requires to see if they supply suitable CMake configuration files. If they do not, then CMake provide documentation on writing modules to find packages that do not supply these files. Geant4 cannot provide support for any third party package your project uses, and any questions should be direct to that package’s authors.

Building an Application against a Build of Geant4

A typical use case for Geant4 developers is to build small testing applications against a fresh build of Geant4. If rebuilds are frequent, then the testing application builds are also frequent.

CMake can be used to build these test applications using find_package and Geant4Config.cmake, as a special version of the latter is created in the Geant4 build directory. This sets up the variables to point to the headers in the Geant4 source directory, and the freshly built libraries in the current build directory.

Applications may therefore be built against a non-installed build of Geant4 by running CMake for the application and setting Geant4_DIR to point to the current build directory of Geant4.

GNUMake System: Makefiles and Environment Variables

This section describes how the Geant4 GNUMake infrastructure is implemented in Geant4 and provides a quick reference guide for the user about the most important environment variables that can be set to configure its behaviour.

This system is now deprecated, though it is still provided through the SVN repository for developers, and is installed by CMake to provide temporary backward compatibility for user applications.

Geant4Make System

As described in How to Define the main() Program of the Installation Guide, the GNUmake process in Geant4 is mainly controlled by the following GNUmake script files (*.gmk scripts are placed in $G4INSTALL/config):

  • architecture.gmk: defining all the architecture specific settings and paths. System settings are stored in $G4INSTALL/config/sys in separate files.
  • common.gmk: defining all general GNUmake rules for building objects and libraries.
  • globlib.gmk: defining all general GNUmake rules for building compound libraries.
  • binmake.gmk: defining the general GNUmake rules for building executables.
  • GNUmake scripts: placed inside each directory in the G4 distribution and defining directives specific to build a library (or a set of sub-libraries) or and executable.

To build a single library (or a set of sub-libraries) or an executable, you must explicitly change your current directory to the one you’re interested in and invoke the “make” command from there (“make global” for building a compound library). Here is a list of the basic commands or GNUmake “targets” one can invoke to build libraries and/or executables:

  • make

    starts the compilation process for building a kernel library or a library associated with an example. Kernel libraries are built with maximum granularity, i.e. if a category is a compound, this command will build all the related sub-libraries, not the compound one. The top level GNUmakefile in $G4INSTALL/source will also build in this case a dependency map libname.map of each library to establish the linking order automatically at the bin step. The map will be placed in $G4LIB/$G4SYSTEM.

  • make global

    starts the compilation process to build a single compound kernel library per category. If issued after “make”, both ‘granular’ and ‘compound’ libraries will be available (NOTE: this will consistently increase the disk space required. Compound libraries will then be selected by default at link time, unless G4LIB_USE_GRANULAR is specified).

  • make bin or make (only for examples/)

    starts the compilation process to build an executable. This command will build implicitly the library associated with the example and link the final application. It assumes all kernel libraries are already generated and placed in the correct $G4INSTALL path defined for them.

    The linking order is controlled automatically in case libraries have been built with maximum granularity, and the link list is generated on the fly.

  • make dll

    On Windows systems this will start the compilation process to build single compound kernel library per category and generate Dynamic Link Libraries (DLLs). Once the libraries are generated, the process will imply also the deletion of all temporary files generated during the compilation.

lib/ bin/ and tmp/ directories

The $G4INSTALL environment variable specifies where the installation of the Geant4 toolkit should take place, therefore kernel libraries will be placed in $G4INSTALL/lib. The $G4WORKDIR environment variable is set by the user and specifies the path to the user working directory; temporary files (object-files and data products of the installation process of Geant4) will be placed in $G4WORKDIR/tmp, according to the system architecture used. Binaries will be placed in $G4WORKDIR/bin, according to the system architecture used. The path to $G4WORKDIR/bin/$G4SYSTEM should be added to $PATH in the user environment.

Environment variables

Here is a list of the most important environment variables defined within the Geant4 GNUmake infrastructure, with a short explanation of their use.

Warning

We recommend that those environment variables listed here and marked with (*) NOT be overridden or set (explicitly or by accident). They are already set and used internally in the default setup !

System configuration

$CLHEP_BASE_DIR
Specifies the path where the CLHEP package is installed in your system.
$USOLIDS_BASE_DIR
Specifies the path where the USolids package is installed in your system.
$G4SYSTEM
Defines the architecture and compiler currently used.

Note

This variable is set automatically if the Configure script is adopted for the installation. This will result in the proper settings also for configuring the environment with the generated shell scripts env.[c]sh.

Installation paths

$G4INSTALL
Defines the path where the Geant4 toolkit is located. It should be set by the system installer. By default, it sets to $HOME/geant4, assuming the Geant4 distribution is placed in $HOME .
$G4BASE (*)
Defines the path to the source code. Internally used to define $CPPFLAGS and $LDFLAGS for -I and -L directives. It has to be set to $G4INSTALL/src.
$G4WORKDIR
Defines the path for the user’s workdir for Geant4. It is set by default to $HOME/geant4, assuming the user’s working directory for Geant4 is placed in $HOME.
$G4INCLUDE
Defines the path where source header files may be mirrored at installation by issuing gmake includes (default is set to $G4INSTALL/include)
$G4BIN, $G4BINDIR (*)
Used by the system to specify the place where to store executables. By default they’re set to $G4WORKDIR/bin and $G4BIN/$G4SYSTEM respectively. The path to $G4WORKDIR/bin/$G4SYSTEM should be added to $PATH in the user environment. $G4BIN can be overridden.
$G4TMP, $G4TMPDIR (*)
Used by the system to specify the place where to store temporary files products of the compilation/build of a user application or test. By default they’re set to $G4WORKDIR/tmp and $G4TMP/$G4SYSTEM respectively. $G4TMP can be overridden.
$G4LIB, $G4LIBDIR (*)
Used by the system to specify the place where to install libraries. By default they’re set to $G4INSTALL/lib and $G4LIB/$G4SYSTEM respectively. $G4LIB can be overridden.

Build specific

$G4TARGET
Specifies the target (name of the source file defining the main()) of the application/example to be built. This variable is set automatically for the examples and tests placed in $G4INSTALL/examples .
$G4DEBUG
Specifies to compile the code (libraries or examples) including symbolic information in the object code for debugging. The size of the generated object code can increase considerably. By default, code is compiled in optimised mode ($G4OPTIMISE set).
$G4OPTDEBUG
Only available for the g++ compiler, specifies to compile the code (libraries or examples) in optimised mode, but including symbolic information in the object code for debugging.
$G4USE_STD11
Specifies to compile the code (libraries or examples) with C++11 Standard enabled on compilers supporting the C++11 Standard.
$G4NO_OPTIMISE
Specifies to compile the code (libraries or examples) without compiler optimisation.
$G4PROFILE
On Linux systems with the g++ compiler, it allows to build libraries with profiling setup for monitoring with the gprof tool.
$G4_NO_VERBOSE
Geant4 code is compiled by default in high verbosity mode ($G4VERBOSE flag set). For better performance, verbosity code can be left out by defining $G4_NO_VERBOSE.
$G4LIB_BUILD_SHARED
Flag specifying if to build kernel libraries as shared libraries (libraries will be then used by default). If not set, static archive libraries are built by default.
$G4LIB_BUILD_STATIC
Flag specifying if to build kernel libraries as static archive libraries in addition to shared libraries (in case $G4LIB_BUILD_SHARED is set as well).
$G4LIB_BUILD_DLL (*)
Internal flag for specifying to build DLL kernel libraries for Windows systems. The flag is automatically set when requested to build DLLs.
$G4LIB_USE_DLL
For Windows systems only. Flag to specify to build an application using the installed DLL kernel libraries for Windows systems. It is required to have this flag set in the environment in order to successfully build an application if the DLL libraries have been installed.
$G4LIB_USE_GRANULAR
To force usage of “granular” libraries against “compound” libraries at link time in case both have been installed. The Geant4 building system chooses “compound” libraries by default, if installed.

UI specific

The most relevant flags for User Interface drivers are just listed here. A more detailed description is given also in section 2. of this User’s Guide.

G4UI_USE_TERMINAL
Specifies to use dumb terminal interface in the application to be built (default).
G4UI_USE_TCSH
Specifies to use the tcsh-shell like interface in the application to be built.
G4UI_BUILD_XM_SESSION
Specifies to include in kernel library the XM Motif-based user interfaces.
G4UI_USE_XM
Specifies to use the XM interfaces in the application to be built.
G4UI_BUILD_WIN32_SESSION
Specifies to include in kernel library the WIN32 terminal interface for Windows systems.
G4UI_USE_WIN32
Specifies to use the WIN32 interfaces in the application to be built on Windows systems.
G4UI_BUILD_QT_SESSION
Specifies to include in kernel library the Qt terminal interface. $QTHOME should specify the path where Qt libraries and headers are installed
G4UI_USE_QT
Specifies to use the Qt interfaces in the application to be built.
G4UI_NONE
If set, no UI sessions nor any UI libraries are built. This can be useful when running a pure batch job or in a user framework having its own UI system.

Visualization specific

The most relevant flags for visualization graphics drivers are just listed here. A description of these variables is given also in section 2. of this User’s Guide.

$G4VIS_BUILD_OPENGLX_DRIVER
Specifies to build kernel library for visualization including the OpenGL driver with X11 extension. It requires $OGLHOME set (path to OpenGL installation).
$G4VIS_USE_OPENGLX
Specifies to use OpenGL graphics with X11 extension in the application to be built.
$G4VIS_BUILD_OPENGLXM_DRIVER
Specifies to build kernel library for visualization including the OpenGL driver with XM extension. It requires $OGLHOME set (path to OpenGL installation).
$G4VIS_USE_OPENGLXM
Specifies to use OpenGL graphics with XM extension in the application to be built.
G4VIS_BUILD_OPENGLQT_DRIVER
Specifies to build kernel library for visualization including the OpenGL driver with Qt extension. It requires $QTHOME set to specify the path where Qt libraries and headers are installed.
G4VIS_USE_OPENGLQT
Specifies to use OpenGL graphics with Qt extension in the application to be built.
$G4VIS_BUILD_OI_DRIVER
Specifies to build kernel library for visualization including the OpenInventor driver. It requires $OIHOME set (paths to the OpenInventor installation).
$G4VIS_USE_OI
Specifies to use OpenInventor graphics in the application to be built.
$G4VIS_BUILD_OIX_DRIVER
Specifies to build the driver for the free X11 version of OpenInventor.
$G4VIS_USE_OIX
Specifies to use the free X11 version of OpenInventor.
$G4VIS_BUILD_RAYTRACERX_DRIVER
Specifies to build kernel library for visualization including the Ray-Tracer driver with X11 extension. It requires X11 installed in the system.
$G4VIS_USE_RAYTRACERX
Specifies to use the X11 version of the Ray-Tracer driver.
$G4VIS_BUILD_OIWIN32_DRIVER
Specifies to build the driver for the free X11 version of OpenInventor on Windows systems.
$G4VIS_USE_OIWIN32
Specifies to use the free X11 version of OpenInventor on Windows systems.
$G4VIS_BUILD_DAWN_DRIVER
Specifies to build kernel library for visualization including the driver for DAWN.
$G4VIS_USE_DAWN
Specifies to use DAWN as a possible graphics renderer in the application to be built.
$G4DAWN_HOST_NAME
To specify the hostname for use with the DAWN-network driver.
$G4VIS_NONE
If specified, no visualization drivers will be built or used.

Hadronic physics specific

$G4NEUTRONHP_USE_ONLY_PHOTONEVAPORATION
When using high precision neutron code, user may choose to force the use of Photon Evaporation model instead of using the neutron capture final state data.
$G4NEUTRONHP_SKIP_MISSING_ISOTOPES
User can force high precision neutron code to use only exact isotope data files instead of allowing nearby isotope files to be used. If the exact file is not available, the cross section will be set to zero and a warning message will be printed.
$G4NEUTRONHP_NEGLECT_DOPPLER
Sets neglecting Doppler broadening mode for boosting performance.

GDML, zlib and g3tog4 modules

$G4LIB_BUILD_GDML
If set, triggers compilation of a plugin module gdml for allowing import/export of detector description setups (geometrical volumes, solids, materials, etc.). By default, the flag is not set; if set, the path to the installation of XercesC package must be specified through the variable $XERCESCROOT.
$G4LIB_USE_GDML
Specifies to use the gdml module. The flag is automatically set if $G4LIB_BUILD_GDML is set in the environment.
$G4LIB_USE_USOLIDS
Specifies to adopt the USolids primitives in place of the original Geant4 solids.
$G4LIB_BUILD_ZLIB
If set, triggers compilation of a specific zlib module for the compression of output files (mainly in use currently for the HepRep graphics driver). By default, the flag is not set and the built-in system library for compression is adopted instead. Setting this flag will also implicitly set the flag below. On Windows systems, if OpenGL or OpenInventor visualization drivers are built, this module is automatically built.
$G4LIB_USE_ZLIB
Specifies to use the zlib module, either system built-in or Geant4 specific.
$G4LIB_BUILD_G3TOG4
If set, triggers compilation of the g3tog4 module for conversions of simple legacy geometries descriptions to Geant4. By default, the flag is not set and the module’s library is not built. Setting this flag will also implicitly set the flag below.
$G4LIB_USE_G3TOG4
Specifies to use the g3tog4 module, assuming the related library has been already installed.

Analysis specific

$G4ANALYSIS_USE
Specifies to activate the appropriate environment for analysis, if an application includes code for histogramming based on AIDA. Additional setup variables are required ($G4ANALYSIS_AIDA_CONFIG_CFLAGS, $G4ANALYSIS_AIDA_CONFIG_LIBS) to define config options for AIDA (“aida-config --cflags” and “aida-config --libs”). See installation instructions of the specific analysis tools for details.

Directory paths to Physics Data

$G4NEUTRONHPDATA
Path to external data set for Neutron Scattering processes.
$G4NEUTRONXSDATA
Path to external data set for evaluated neutron cross-sections.
$G4LEDATA
Path to external data set for low energy electromagnetic processes.
$G4PIIDATA
Path to external data set for shell ionisation cross-sections.
$G4LEVELGAMMADATA
Path to the data set for Photon Evaporation.
$G4RADIOACTIVEDATA
Path to the data set for Radiative Decay processes.
$G4ENSDFSTATE1.0
Path to the data set for NuclideTable
$G4ABLADATA
Path to nuclear shell effects data set for INCL/ABLA hadronic model.
$G4REALSURFACEDATA
Path to the data set for measured optical surface reflectance for precise optical physics.

Linking External Libraries with Geant4

The Geant4 GNUmake infrastructure allows to extend the link list of libraries with external (or user defined) packages which may be required for some user’s applications to generate the final executable.

Adding external libraries which do not use Geant4

In the GNUmakefile of your application, before including binmake.gmk, specify the extra library in EXTRALIBS either using the -L...-l... syntax or by specifying the full pathname, e.g.:

EXTRALIBS := -L<your-path>/lib -l<myExtraLib>

or

EXTRALIBS := <your-path>/lib/lib<myExtraLib>.a

You may also specify EXTRA_LINK_DEPENDENCIES, which is added to the dependency of the target executable, and you may also specify a rule for making it, e.g.:

EXTRA_LINK_DEPENDENCIES := <your-path>/lib/lib<myExtraLib>.a

<your-path>/lib/lib<myExtraLib>.a:
      cd <your-path>/lib; $(MAKE)

Note that you almost certainly need to augment CPPFLAGS for the header files of the external library, e.g.:

CPPFLAGS+=-I<your-path>/include

See Listing 94.

Listing 94 An example of a customised GNUmakefile for an application or example using an external module not bound to Geant4.
# --------------------------------------------------------------------
# GNUmakefile for the application "sim" depending on module "Xplotter"
# --------------------------------------------------------------------

name := sim
G4TARGET := $(name)
G4EXLIB := true

CPPFLAGS  += -I$(HOME)/Xplotter/include
EXTRALIBS += -L$(HOME)/Xplotter/lib -lXplotter
EXTRA_LINK_DEPENDENCIES := $(HOME)/Xplotter/lib/libXplotter.a

.PHONY: all

all: lib bin

include $(G4INSTALL)/config/binmake.gmk

$(HOME)/Xplotter/lib/libXplotter.a:
        cd $(HOME)/Xplotter; $(MAKE)

Adding external libraries which use Geant4

In addition to the above, specify, in EXTRALIBSSOURCEDIRS, a list of directories containing source files in its src/ subdirectory. Thus, your GNUmakefile might contain:

EXTRALIBS += $(G4WORKDIR)/tmp/$(G4SYSTEM)/<myApp>/lib<myApp>.a \
             -L<your-path>/lib -l<myExtraLib>
EXTRALIBSSOURCEDIRS += <your-path>/<myApp> <your-path>/<MyExtraModule>
EXTRA_LINK_DEPENDENCIES := $(G4WORKDIR)/tmp/$(G4SYSTEM)/<myApp>/lib<myApp>.a

MYSOURCES := $(wildcard <your-path>/<myApp>/src/*cc)
$(G4WORKDIR)/tmp/$(G4SYSTEM)/<myApp>/lib<myApp>.a: $(MYSOURCES)
      cd <your-path>/<myApp>; $(MAKE)

See the Listing 95.

Listing 95 An example of a customised GNUmakefile for an application or example using external modules bound to Geant4.
# -----------------------------------------------------------------
# GNUmakefile for the application "phys" depending on module "reco"
# -----------------------------------------------------------------

name := phys
G4TARGET := $(name)
G4EXLIB := true

EXTRALIBS += $(G4WORKDIR)/tmp/$(G4SYSTEM)/$(name)/libphys.a \
             -L$(HOME)/reco/lib -lreco
EXTRALIBSSOURCEDIRS += $(HOME)/phys $(HOME)/reco
EXTRA_LINK_DEPENDENCIES := $(G4WORKDIR)/tmp/$(G4SYSTEM)/$(name)/libphys.a

.PHONY: all
all: lib bin

include $(G4INSTALL)/config/binmake.gmk

MYSOURCES := $(wildcard $(HOME)/phys/src/*cc)
$(G4WORKDIR)/tmp/$(G4SYSTEM)/$(name)/libphys.a: $(MYSOURCES)
        cd $(HOME)/phys; $(MAKE)