📄️ Alias
This macro can be used to register an alias for a named element. Both the name registered under the element registration macro (e.g., SSTELIREGISTER_COMPONENT) and with this macro will point to the same element. Note that sst-info will display the element under its non-aliased name but will show the alias as an alternative. This macro is especially useful for changing an element name without breaking existing configuration files. The old name should be registered using the alias macro and the new name should be used in the element registration macro.
📄️ Component
All components must register themselves with SST using this macro. The library and name strings provided in this macro
📄️ Component Base
This macro enables a class that inherits directly from SST::Component but is not itself a Component (e.g., the class is intended to be a base class for other component classes) to register ELI information and have that information inherited by its child component classes.
📄️ Component Derived Base
This macro registers the inheritance chain for a class that does not directly inherit from SST::Component and is not itself intended to be an SST Component, but will be the base class for an SST Component. Registering these classes allows SST to identify which ELI information should be inherited by a child Component. The names provided to the macro must be the fully qualified class names. ELI documentation macros declared by this class will be inherited by child classes.
📄️ Console
InteractiveConsoles must register themselves with SST using this macro. The library and name strings provided in this macro will be used by SST to identify the console as "library.name". The version and description fields document the version and purpose of the console.
📄️ Module
All modules must register themselves with SST using this macro. The library and name strings provided in this macro will be used by SST to identify the module as "library.name". The version and description are displayed by sst-info to document the version and purpose of the Module. The apiclassname field is used to enable ELI inheritance.
📄️ Module API
A module API defines the API for a particular variety of SST Modules. This macro is used to register a class that defines a module API with the SST Core. This class should also inherit from SST::Module. If instead this class inherits from another Module API, the SSTELIREGISTERMODULEDERIVEDAPI. A class may be both a module API and a module itself and include both registration macros. Modules that inherit from the registered API will also inherit any ELI documented by the API class.
📄️ Module Derived API
If a module API inherits from another module API, the "derived" or child API should use this macro to register itself. Modules that implement the API registered in this call will inherit all ELI documented by this API as well as any the API inherits from.
📄️ Partitioner
All partitioners must register themselves with SST using this macro. The library and name strings provided in this macro
📄️ PortModule
All PortModules must register themselves with SST using this macro. The library and name strings provided in this macro will be used by SST to identify the port module as "library.name". The version and description are displayed by sst-info to document the version and purpose of the module.
📄️ Profile Tool
This macro is used to register a profiling tool with SST. The library and name strings provided in this macro will be used by SST to identify the tool as "library.name". The version and description are displayed
📄️ Python Module
Libraries can implement python modules to assist with, for example, configuration. Such modules use this macro to register with the SST Core. Modules will be available as submodules in the 'sst' python module.
📄️ RealTimeAction
RealTimeActions must register themselves with SST using this macro. The library and name strings provided in this macro will be used by SST to identify the action as "library.name". The version and description fields document the version and purpose of the action.
📄️ SubComponent
All SubComponents must register themselves with SST using this macro. The library and name strings provided in this macro will be used by SST to identify the subcomponent as "library.name". The version, description, and category are displayed by sst-info to document the version and purpose of the SubComponent. The interface declares which SubComponent API this subcomponent implements which is used to check compatibility with SubComponent slots. The interface must also be registered with SST using the SSTELIREGISTERSUBCOMPONENTAPI or SSTELIREGISTERSUBCOMPONENTDERIVEDAPI macro.
📄️ SubComponent API
SubComponents implement a specific API and SubComponent slots require any SubComponents loaded into them to implement a specific API. This macro registers SubComponent APIs with SST Core. If a SubComponent API inherits from another registered SubComponent API (as opposed to, for example, SST::SubComponent directly), the API should instead register using the SSTELIREGISTERSUBCOMPONENTDERIVEDAPI macro.
📄️ SubComponent Derived API
If a subcomponent API inherits from another subcomponent API, the "derived" or child API should use this macro to register itself. SubComponents that implement the API registered in this call will inherit all ELI documented by this API as well as any the API inherits from.