0.8.9 Release

Again we managed to do an amazing feature release in just two month. In 416 commits we modified 393 files with 23462 insertions(+) and 9046 deletions(-).

Most awaited

The most awaited feature in this release is certainly the qt-gui developed by Raffael Pancheri. It includes a rich feature set including searching, unmounting, importing and exporting. A lot of functionality is quite stable now, even though its version is 0.0.1 alpha. If you find any bugs or want to give general feedback, feel free to use the issue tracker of the Elektra project. A screenshot can be found here To compile it (together with Elektra), see the README here

Manuel Mausz also has been very active and developed glib+gi bindings. These bindings make Elektra more friendly to the glib/gtk/gnome world. Using the gobject introspection python3 and lua bindings were developed. Additionally he got rid of all clang warnings.

Felix Berlakovich also made progress: the ini plugin now supports multiline and which can be dynamically turned on and off, i.e. during mounting (thanks to Felix)

Last, but not least, Kai-Uwe ported Elektra to Windows7. MinGW is now one more supported compiler (tested on build-server, see later). Astonishingly, it was only little effort necessary: Basically we only needed a new implementation of the resolver, which is now called wresolver. Different from the resolver it lacks the sophisticated multi-process and multi-thread atomicity properties. On the plus side we now have a resolver that is very easy to study and understand and still works as file resolver (noresolver does not).


ABI/API of the C-API is still completely stable even though under the hood a lot was changed. All testcases compiled against the previous version still run against Elektra 0.8.9.

This is, however, not the case for libtools. For MinGW porting it was necessary to rename an enum related to merging because it conflicted with an already defined MACRO.

For maintainers also some changes are necessary. For MinGW and to actually use the flexibility of the new resolver variants two new CMake Variables are introduced: KDB_DEFAULT_RESOLVER and KDB_DEFAULT_STORAGE.

More importantly for maintainers the CMake variables regarding SWIG bindings are now abandoned in favour to the new variable BINDINGS that works like PLUGINS and TOOLS. Just start with


and CMake should remove the bindings that have missing dependencies on your system. Remember that glib and gi (i.e. gi_python3 and gi_lua) bindings were introduced, too. Additionally, the cpp binding can now be deactivated if not added to BINDINGS.

Finally, the gen tool added a Python package called support.

Other Bits

A proof of concept storage plugin regexstore was added. It allows one to capture individual configuration options within an otherwise not understood configuration file (e.g. for vimrc or emacs where the configuration file may contain programming constructs).

Most tests now also work with the BUILD_SHARED variant (from our knowledge all would work now, but some are still excluded if BUILD_FULL and BUILD_STATIC is disabled. Please report issues if you want to use uncommon CMake combinations).

A small but very important step towards specifying configuration files is the new proposed API method ksLookupBySpec (and ksLookup implementing cascading search). It introduces a logical view of configuration that in difference to the physical view of configuration does not have namespaces, but everything is below the root "/". Additionally, contextual values now allow one to be compile-time configured using C++-Policies. These are small puzzle pieces that will fit into a greater picture at a later time.

A (data) race detection tool was implemented. Using it a configurable number of processes and threads it tries to kdbSet() a different configuration at (nearly) the same time.

With this tool the resolver could be greatly be improved (again). It now uses stat with nanosecond precision that will be updated for every successful kdbSet(). Even if the configuration file was modified manually (not using Elektra) the next kdbSet() then is much more likely to fail. Additionally a recursive mutex now protects the file locking mechanism.

The build server now additionally has following build jobs:

Many more examples were written and are used within doxygen. Most snippets now can also be found in compilable files:

Most plugins now internally use the same CMake function add_plugin which makes plugin handling more consistent.

Felix converted the METADATA spec to ini files and added a proposal how comments can be improved.




Get It!

You can download the release from here

already built API-Docu can be found here

For more information, see https://www.libelektra.org

Best regards, Markus