HPX relies on loading application specific components during the runtime of an application. Moreover, HPX comes with a set of preinstalled components supporting basic functionalities useful for almost every application. Any component in HPX is loaded from a shared library, where any of the shared libraries can contain more than one component type. During startup, HPX tries to locate all available components (e.g. their corresponding shared libraries) and creates an internal component registry for later use. This section describes the algorithm used by HPX to locate all relevant shared libraries on a system. As described, this algorithm is customizable by the configuration properties loaded from the ini files (see section Loading INI Files).
Loading components is a two stage process. First HPX tries to locate all component shared libraries, loads those, and generates default configuration section in the internal configuration database for each component found. For each found component the following information is generated:
[hpx.components.<component_instance_name>] name = <name_of_shared_library> path = $[component_path] enabled = $[hpx.location]/lib/hpx/ default = 1
The values in this section correspond to the expected configuration information for a component as described in the section Built-in Default Configuration Settings.
In order to locate component shared libraries, HPX
will try loading all shared libraries (files with the platform specific
extension of a shared library, Linux:
*.dylib) found in the directory referenced
by the ini property
This first step corresponds to step 1) during the process of filling the internal configuration database with default information as described in section Loading INI Files.
After all of the configuration information has been loaded, HPX
performs the second step in terms of loading components. During this
step, HPX scans all existing configuration sections
[hpx.component.<some_component_instance_name>] and instantiates a special factory
object for each of the successfully located and loaded components. During
the application's life time, these factory objects will be responsible
to create new and discard old instances of the component they are associated
with. This step is performed after step 11) of the process of filling
the internal configuration database with default information as described
in section Loading