Recommendations for requirements files
Contents
Building libraries
Summary of recommendations for building libraries
Miscellaneous recommendations
The
Gaudi manual
contains a good discussion of the different library types, see Chapter "Framework libraries".
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" };
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 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.
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
- 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
- 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.
Revised:
08/14/03
e-mail:
Traudl Kozanecki