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

dawagner / parameter-framework / 285 / 1
0%
master: 78%

Build:
Build:
LAST BUILD BRANCH: integerparam-template
DEFAULT BRANCH: master
Ran 28 Sep 2015 04:32PM UTC
Files 233
Run time 6s
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

28 Sep 2015 04:32PM UTC coverage: 72.601% (-0.004%) from 72.605%
285.1

push

travis-ci

dawagner
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.

If the plugin entry point API changes, we will change the name of the macro
(it contains a version number), which will cause the plugins to raise an error
at compile time instead of failing at runtime. Ths entry point's signature is
also checked at compile time.

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 SubsystemLibrary and
SystemClass: everything the plugin needs to know is put under SubsystemLibrary
and the rest under SystemClass - which is the class responsible for loading the
plugins.

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

4804 of 6617 relevant lines covered (72.6%)

3461.94 hits per line

Source Files on job 285.1
  • Tree
  • List 0
  • Changed 4
  • Source Changed 4
  • Coverage Changed 3
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Build 285
  • Travis Job 285.1
  • d7148e7a on github
  • Prev Job for on rework-plugin-entrypoint-api (#280.1)
  • Next Job for on rework-plugin-entrypoint-api (#295.1)
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