• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

dawagner / parameter-framework / 296
0%
master: 78%

Build:
Build:
LAST BUILD BRANCH: integerparam-template
DEFAULT BRANCH: master
Ran 29 Sep 2015 02:06PM UTC
Jobs 2
Files 233
Run time 940031min
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

pending completion
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

Jobs
ID Job ID Ran Files Coverage
1 296.1 13 Jul 2017 09:17AM UTC 0
25.35
Travis Job 296.1
2 296.2 29 Sep 2015 02:06PM UTC 0
0.0
Travis Job 296.2
Source Files on build 296
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #296
  • fd3cc149 on github
  • Prev Build on rework-plugin-entrypoint-api (#295)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc