Recommendations for requirements files

Contents

Building libraries
Summary of recommendations for building libraries
Miscellaneous recommendations


Building libraries

The Gaudi manual contains a good discussion of the different library types, see Chapter "Framework libraries".

Component libraries:
Algorithms, Auditors, Services, Tools, Converters

These packages have two files in /src/Dll, one which declares the components, the other to load them,

<package>_dll.cxx and <package>_load.cxx .
Component libraries are loaded dynamically during run-time, they should not be linked against. They do not export their symbols except for a special one, getFactoryEntries(). Changes in a component library do not require the application to be relinked.

Component libraries are specified at run-time in the joboptions file,

ApplicationMgr.Dlls += { "MyComponent1", "MyComponent2" };

Linker libraries

These libraries export all their symbols and are needed during the linking phase in application building. They can be linked to the application either statically or dynamically. Naming conventions on Linux: lib<library>.a or <library>.so, respectively. The search path is given with the -L option and the library name with -l. Locating and loading the proper shared library at run-time is done using the LD_LIBRARY_PATH environment variable.

Dual-purpose libraries and library strategy

Dual-purpose libraries are simultaneously component and linker libraries. For example, they may be component libraries, because they have factories associated, but in addition clients may need access to header files and code (linker library). See the Gaudi manual for recommendations, how to handle this case (Section "Dual purpose libraries and library strategy"). In short: It is recommended that three different packages be used for this: one pure component package for the Algorithms, one dual-purpose for the DataObjects, and one pure linker package for the helper classes.

CMT use-option   -no_auto_imports   and
constituent-option   -import=package-name

By default CMT imports automatically into the "using" package a set of standard macros, which are specified by used packages. This feature can be switched off by adding to the use statement
use   Xxx   -no_auto_imports
or re-activated using the statement
use   Xxx   -auto_imports
When discarded, each constituent (library or application), which needs to link against the non-imported package, has to explicitly import the macros with the option   -import=<package>.
Example: requirements of GaudiSvc
use HTL v2r*   -no_auto_imports

# build the component library
library GaudiSvc   -import=HTL \
ApplicationMgr/*.cpp \
AuditorSvc/*.cpp \
HistogramSvc/*.cpp \
etc
As a result of the import the <import>_linkopts in a pattern like library_Clinkopts will contain the forced (-u) linking of the HTL library,
-u   GaudiSvc_loadref   $HTL_linkopts
Back to Top

Summary of recommendations for building libraries

Component library
apply_pattern component_library library="<package>"
No library_stamps are needed
Linker library
apply_pattern linker_library library="<package>"
Dual purpose library
# The library name is <package>Lib
apply_pattern package_Lstamps
apply pattern pattern package_Llinkopts
apply_pattern package_Lshlibflags
Shared library (not Gaudi Dll construct)
apply_pattern shared_library
Back to Top

Miscellaneous recommendations

Definitions used only within the scope of the package

Move definitions of macros, sets and modifications of PATH or LD_LIBRARY_PATH (path_append, path_prepend), which are needed only within the context of the package, under private.
If a modification of cppflags is needed, do not modify cppflags, but define <package>_cppflags and make it private.

This helps to keep the PATH or LD_LIBRARY_PATH short, and avoids to have hundreds of environment variables and macros in a release.

path_append or path_prepend

When using the statement path_append, whether within private or public scope, always cleanup the path (path_remove) before appending to the path.

package_test and dummy_test

The test program should be private. This was not done in the past, because the set statement did not work under private.
Back to Top

Revised: 08/14/03
e-mail: Traudl Kozanecki