dawagner / parameter-framework
0%
master: 78%

LAST BUILD BRANCH: integerparam-template
DEFAULT BRANCH: master
Repo Added
Files 130
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

LAST BUILD ON BRANCH rework-plugin-entrypoint-api
branch: rework-plugin-entrypoint-api
CHANGE BRANCH
x

296

push

travis-ci

David Wagner 
Rework the plugin entry-point API to be a well-known symbol name

The plugins' entry-point used to be a symbol which name was constructed based on
the library name but the Parameter Framework was trying to deduce it based on
how library files are usually named on Linux, i.e. prefixed with "lib", then the
soname, then ".so".

This is not always true on Linux and this is usually false on Windows.

Also, if the API of this symbol changes, there is no way to know at
compile-time.

Which is why this rework introduces a macro to be used by plugins. This macro
is the name of the entry-point symbol to be declared by plugins and will be
retrieved by the Parameter Framework.

A new header is added and exported to plugins: Plugin.h. This header declares
the entry-point and also declares it to be visible (a private entry-point
would be useless). Plugins should use this header in the file defining their
entry-point.

For now, we only support one API version at a time: if the API changes from V1
to V2, the plugins won't compile and the Parameter Framework won't recognize
previously-compiled plugins using V1. If we want backward-compatibility, we can
add it later by declaring both macros (V1 and V2) and trying to find the symbol
corresponding to V1 if the symbol corresponding to V2 can't be found.

The first name of the macro is: PARAMETER_FRAMEWORK_PLUGIN_ENTRYPOINT_V1

Implementation detail: the implementation is split between Plugin.h,
SubsystemLibrary and SystemClass: everything the plugin needs to know is put
under Plugin.h, what must be shared between the plugin and the core is under
Subsystemlibrary and the parts private to the core are under SystemClass - which
is the class responsible for loading the plugins.

Signed-off-by: David Wagner <david.wagner@intel.com>

0 of 0 relevant lines covered (NaN%)

0.0 hits per line

Relevant lines Covered
0 RELEVANT LINES 0 COVERED LINES
0.0 HITS PER LINE
Source Files on rework-plugin-entrypoint-api
Detailed source file information is not available for this build.

Recent builds

Builds Branch Commit Type Ran Committer Via Coverage
296 rework-plugin-entrypoint-api Rework the plugin entry-point API to be a well-known symbol name The plugins' entry-point used to be a symbol which name was constructed based on the library name but the Parameter Framework was trying to deduce it based on how library files are ... push David Wagner travis-ci pending completion  
295 rework-plugin-entrypoint-api Rework the plugin entry-point API to be a well-known symbol name The plugins' entry-point used to be a symbol which name was constructed based on the library name but the Parameter Framework was trying to deduce it based on how library files are ... push David Wagner travis-ci pending completion  
285 rework-plugin-entrypoint-api Rework the plugin entry-point API to be a well-known symbol name The plugins' entry-point used to be a symbol which name was constructed based on the library name but the Parameter Framework was trying to deduce it based on how library files are ... push dawagner travis-ci pending completion  
280 rework-plugin-entrypoint-api Rework the plugin entry-point API to be a well-known symbol name The plugins' entry-point used to be a symbol which name was constructed based on the library name but the Parameter Framework was trying to deduce it based on how library files are ... push dawagner travis-ci pending completion  
See All Builds (362)