Skip to content
This repository has been archived by the owner on Aug 5, 2022. It is now read-only.

Version 3.0.0
Compare
Choose a tag to compare
@dawagner dawagner released this 23 Oct 08:57
· 312 commits to master since this release
v3.0.0
aca04cb

The most significant change is the official support of Windows. Details follow. This version changes the Plugin API with 2.x.x versions hence the increase in major version number. Details follow.

In bold, the changes that are likely to have an impact for integrators of the Parameter Framework.

Major changes:

Windows support

  • Compilation has been tested with Visual Studio 12 (2013) 64bits, using both the Visual Studio and the NMake build system generators provided by CMake.
  • Run the legacy test suite on Windows. It was using UNIX-specific constructs but has been reworked to be portable.

Features

  • Binary export of settings has been suppressed (We didn't know of anyone using it).
  • Removed the "big endian subsystem" feature. We never heard of anyone using it and it wasn't correctly tested. We have added this feature in the long-term requirements documentation. The "BigEndian" XML attribute is now invalid with regard to XSD validation but the code will silently ignore it.
  • Starting the remote interface no longer depends on the presence of the remote-processor library: it now solely depends on the "TuningAllowed" attribute in the toplevel configuration.

Plugins

The API provided to the plugins has changed in a non-retrocompatible way. Plugins need to be adapted. Look at changes in the skeleton-subsystem and the test-subsystem for reference.

  • The plugin entry-point symbol name no longer depends on the name of the library file containing it. Instead, it is fixed and the same for everyone. The entry-point signature has changed.
  • Also, this symbol name is provided as a C macro so that plugin developers don't have to worry about it being incorrect.
  • This macro's name will change whenever the API is changed in a non-retrocompatible way, so that plugin developers will know at compile time that their plugin is broken.
  • As a consequence to the API change, plugins can now log in their constructors and destructors.

Android integration

The Android.mk makefiles have been removed. They may come back later on a dedicated branch or be left as an exercise to the Android integrators. We have done this in order to avoid misalignments between build systems.

Under the hood

  • Compile with C++11 and use some of its feature for both achieving better code quality and portability: C++11 provides support for threading.
  • Use ASIO (standalone version, aka non-boost) for networking in the remote-processor library.
  • Hide non-API symbols (using visibility attribute on GCC/Clang or declspec on Windows)

Minor changes:

Features:

  • test-platform daemonization has been removed (because it was not easily achievable on Windows and can be achieved by the user on Linux)
  • remote-process interactive mode has been removed (it wasn't used much and was relying on a poorly-written and non-portable tokenizer)
  • Support for Floating Point parameters (obeying the IEEE 754 norm)
  • API methods {get,set}SchemaFolderLocation are replaced with {get,set}SchemaUri. As the name suggests, it takes a URI instead of a path but it is retro-compatible (under the hood, it uses functions provided by libxml2 which understands paths as URI).
  • A new parameter adaptation has been added: Logarithmic Adaptation

Build and CI

  • Explicitly depend on CMake 2.8.12 or later (we are using features introduced in that release)
  • We use "AppVeyor" as Windows CI engine.

Tests

  • Test the skeleton-subsystem

Misc

Statistics

Since v2.6.1, 17 issues identified through static analysis were fixed (there used to be 22). Code coverage has improved from 71.42 to 74.11.

Known issues

The "Plugin" API needs rework. Since the plugins can theoretically access all of the data in the Parameter Framework, we need to export so many headers. On Android - because headers are usually not installed but rather "exported" (as a usage requirement, which is similar to how it is done intra-project with CMake) this can lead to a name conflict.

Assets 2
Loading