Component and Linker Libraries

From Daya Bay

Jump to: navigation, search

This topic helps to understand the differences between component and linker libraries and how to correctly build a package with them.

Component vs. Linker Libraries

A linker library provides some public class header files (it may have private ones) and their implementations in a shared library. A user's package must have the headers available so that they can be hard-compiled in.

A component library does not have any public header files. Instead it only provides implementations of Interface classes. A user's package is hard-compiled against the Interface classes (provided in some, posibly different, linker library) but does not need to know of the existence of the component library at compile time. Instead, Gaudi and ROOT will use the job configuration to assure that the right library is linked at run time to provide the needed classes.

Pure Linker Library Package

The cmt/requirements package

Assume the package "LinkerPackage" only provides a linker library. Its cmt/requirements file needs (at least) the following lines:

include_dirs $(LINKERPACKAGEROOT)
apply_pattern install_more_includes more="LinkerPackage"
library LinkerPackage *.cc
apply_pattern linker_library library=LinkerPackage

The package layout

LinkerPackage/
holds all, and only, public headers
src/
holds all *.cc files and any private headers


Pure Component Library Package

The cmt/requirements package

Assume the package "ComponentPackage" only provides a component library. Its cmt/requirements file needs (at least) the following lines:

include_path none
library ComponentPackage *.cc
apply_pattern component_library library=ComponentPackage

In particular note that there is no "include_dirs" line.

The package layout

src/
holds all *.cc files and any private headers

Note: there is no "ComponentPackage/" subdir holding headers.

Package providing both

The cmt/requirements package

While it is not necessary and there is no (?) particular good reason to do this, you can have a package that produces both types of libraries.

Assume the package "HybridPackage" provides both types of libraries. Its cmt/requirements file needs (at least) the following lines:

include_dirs $(HYBRIDPACKAGEROOT)
apply_pattern install_more_includes more="HybridPackage"
library HybridPackageLib lib/*.cc
library HybridPackage components/*.cc
apply_pattern linker_library library=HybridPackageLib
apply_pattern component_library library=HybridPackage

The package layout

There must be a way to separate out the two types of implementation files so that a pattern can be provided to the CMT "library" command. Here the separate subdirectories src/lib/ and src/components are chosen. You are free to choose an other convention.

HybridPackage/
holds all, and only, public headers
src/lib/ 
holds implementation files for classes defined in the HybridPackage/ directory and any private headers
src/components 
holds implementations of classes implementing some interface, private headers and any "HybridPacakge_entries.cc" and "HybridPacakge_load.cc factory registration code.
Personal tools