Repository Summary
Checkout URI | https://github.com/tesseract-robotics/boost_plugin_loader.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2024-09-28 |
Dev Status | DEVELOPED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Packages
Name | Version |
---|---|
boost_plugin_loader | 0.2.2 |
README
Boost Plugin Loader
Plugin loading library based on Boost DLL
Platform | CI Status |
---|---|
Linux (Focal) | |
Windows | |
Lint (Clang-Format) | |
Lint (CMake-Format) | |
Lint (Clang-Tidy) |
Usage
The plugin loader must know the names of the libraries in which to search for plugins. These library names should not contain a prefix (i.e., lib/) or suffix (i.e., .so). The library names can be set in two ways:
- Set the
search_libraries
member directly in code - Add a list of library names to an arbitrary environment variable (separated by colon), and set the
search_libraries_env
member to the name of that environment variable.
The plugin loader must also know the paths in which to look for the specified libraries that contain plugins. These paths can also be set in three ways:
- Set the
search_system_folders
member true. This will allow the plugin loader to look for plugins in directories specified by system environment variables (e.g.,LD_LIBRARY_PATH
). Generally this is the easiest approach. - Set the
search_paths
member directly in code - Add a list of library names to an arbitrary environment variable (separated by colon), and set the
search_paths_env
member to the name of that environment variable
Defining a plugin base class
At a minimum, there are no requirements on the definition of a base class that can be used with this plugin loader.
However, there is one optional requirement for enabling the plugin loader to discover the names of all plugins inheriting a specific base class type.
Namely, the plugin base class must have a member function static std::string getSection()
which defines a section name for the plugin and is accessible to the PluginLoader
and has_getSection
classes.
The section name is a unique 8-byte string that associates implementations to the base class.
The plugin loader method getAvailablePlugins
can identify all symbols in a library with this section name and thereby return all implementations of a particular base class.
It is also generally useful to define a new export macro for the base class that invokes the EXPORT_CLASS_SECTIONED
macro with the section name directly.
See the test plugin base class definition for an example.
Declaring plugin implementations
Creating an implementation of a plugin is as simple as inheriting from the plugin base class, and calling the EXPORT_CLASS_SECTIONED
macro with the correct section
(or calling a custom export macro defined for the plugin base class, described above). See the test plugin implementations for an example.
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/tesseract-robotics/boost_plugin_loader.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2024-09-28 |
Dev Status | DEVELOPED |
CI status | No Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Packages
Name | Version |
---|---|
boost_plugin_loader | 0.2.2 |
README
Boost Plugin Loader
Plugin loading library based on Boost DLL
Platform | CI Status |
---|---|
Linux (Focal) | |
Windows | |
Lint (Clang-Format) | |
Lint (CMake-Format) | |
Lint (Clang-Tidy) |
Usage
The plugin loader must know the names of the libraries in which to search for plugins. These library names should not contain a prefix (i.e., lib/) or suffix (i.e., .so). The library names can be set in two ways:
- Set the
search_libraries
member directly in code - Add a list of library names to an arbitrary environment variable (separated by colon), and set the
search_libraries_env
member to the name of that environment variable.
The plugin loader must also know the paths in which to look for the specified libraries that contain plugins. These paths can also be set in three ways:
- Set the
search_system_folders
member true. This will allow the plugin loader to look for plugins in directories specified by system environment variables (e.g.,LD_LIBRARY_PATH
). Generally this is the easiest approach. - Set the
search_paths
member directly in code - Add a list of library names to an arbitrary environment variable (separated by colon), and set the
search_paths_env
member to the name of that environment variable
Defining a plugin base class
At a minimum, there are no requirements on the definition of a base class that can be used with this plugin loader.
However, there is one optional requirement for enabling the plugin loader to discover the names of all plugins inheriting a specific base class type.
Namely, the plugin base class must have a member function static std::string getSection()
which defines a section name for the plugin and is accessible to the PluginLoader
and has_getSection
classes.
The section name is a unique 8-byte string that associates implementations to the base class.
The plugin loader method getAvailablePlugins
can identify all symbols in a library with this section name and thereby return all implementations of a particular base class.
It is also generally useful to define a new export macro for the base class that invokes the EXPORT_CLASS_SECTIONED
macro with the section name directly.
See the test plugin base class definition for an example.
Declaring plugin implementations
Creating an implementation of a plugin is as simple as inheriting from the plugin base class, and calling the EXPORT_CLASS_SECTIONED
macro with the correct section
(or calling a custom export macro defined for the plugin base class, described above). See the test plugin implementations for an example.
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/tesseract-robotics/boost_plugin_loader.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2024-09-28 |
Dev Status | DEVELOPED |
CI status | No Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Packages
Name | Version |
---|---|
boost_plugin_loader | 0.2.2 |
README
Boost Plugin Loader
Plugin loading library based on Boost DLL
Platform | CI Status |
---|---|
Linux (Focal) | |
Windows | |
Lint (Clang-Format) | |
Lint (CMake-Format) | |
Lint (Clang-Tidy) |
Usage
The plugin loader must know the names of the libraries in which to search for plugins. These library names should not contain a prefix (i.e., lib/) or suffix (i.e., .so). The library names can be set in two ways:
- Set the
search_libraries
member directly in code - Add a list of library names to an arbitrary environment variable (separated by colon), and set the
search_libraries_env
member to the name of that environment variable.
The plugin loader must also know the paths in which to look for the specified libraries that contain plugins. These paths can also be set in three ways:
- Set the
search_system_folders
member true. This will allow the plugin loader to look for plugins in directories specified by system environment variables (e.g.,LD_LIBRARY_PATH
). Generally this is the easiest approach. - Set the
search_paths
member directly in code - Add a list of library names to an arbitrary environment variable (separated by colon), and set the
search_paths_env
member to the name of that environment variable
Defining a plugin base class
At a minimum, there are no requirements on the definition of a base class that can be used with this plugin loader.
However, there is one optional requirement for enabling the plugin loader to discover the names of all plugins inheriting a specific base class type.
Namely, the plugin base class must have a member function static std::string getSection()
which defines a section name for the plugin and is accessible to the PluginLoader
and has_getSection
classes.
The section name is a unique 8-byte string that associates implementations to the base class.
The plugin loader method getAvailablePlugins
can identify all symbols in a library with this section name and thereby return all implementations of a particular base class.
It is also generally useful to define a new export macro for the base class that invokes the EXPORT_CLASS_SECTIONED
macro with the section name directly.
See the test plugin base class definition for an example.
Declaring plugin implementations
Creating an implementation of a plugin is as simple as inheriting from the plugin base class, and calling the EXPORT_CLASS_SECTIONED
macro with the correct section
(or calling a custom export macro defined for the plugin base class, described above). See the test plugin implementations for an example.
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/tesseract-robotics/boost_plugin_loader.git |
VCS Type | git |
VCS Version | main |
Last Updated | 2024-09-28 |
Dev Status | DEVELOPED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Packages
Name | Version |
---|---|
boost_plugin_loader | 0.2.2 |
README
Boost Plugin Loader
Plugin loading library based on Boost DLL
Platform | CI Status |
---|---|
Linux (Focal) | |
Windows | |
Lint (Clang-Format) | |
Lint (CMake-Format) | |
Lint (Clang-Tidy) |
Usage
The plugin loader must know the names of the libraries in which to search for plugins. These library names should not contain a prefix (i.e., lib/) or suffix (i.e., .so). The library names can be set in two ways:
- Set the
search_libraries
member directly in code - Add a list of library names to an arbitrary environment variable (separated by colon), and set the
search_libraries_env
member to the name of that environment variable.
The plugin loader must also know the paths in which to look for the specified libraries that contain plugins. These paths can also be set in three ways:
- Set the
search_system_folders
member true. This will allow the plugin loader to look for plugins in directories specified by system environment variables (e.g.,LD_LIBRARY_PATH
). Generally this is the easiest approach. - Set the
search_paths
member directly in code - Add a list of library names to an arbitrary environment variable (separated by colon), and set the
search_paths_env
member to the name of that environment variable
Defining a plugin base class
At a minimum, there are no requirements on the definition of a base class that can be used with this plugin loader.
However, there is one optional requirement for enabling the plugin loader to discover the names of all plugins inheriting a specific base class type.
Namely, the plugin base class must have a member function static std::string getSection()
which defines a section name for the plugin and is accessible to the PluginLoader
and has_getSection
classes.
The section name is a unique 8-byte string that associates implementations to the base class.
The plugin loader method getAvailablePlugins
can identify all symbols in a library with this section name and thereby return all implementations of a particular base class.
It is also generally useful to define a new export macro for the base class that invokes the EXPORT_CLASS_SECTIONED
macro with the section name directly.
See the test plugin base class definition for an example.
Declaring plugin implementations
Creating an implementation of a plugin is as simple as inheriting from the plugin base class, and calling the EXPORT_CLASS_SECTIONED
macro with the correct section
(or calling a custom export macro defined for the plugin base class, described above). See the test plugin implementations for an example.