Libelektra: code generation for errors

Personally, I prefer option 1. The error codes should change only very infrequently, which makes the additional effort of manually writing the C code and keeping other languages in sync negligible. The initial effort should also be less compared to setting up any form of automatic generation.

Why not option 2?

Mustache templates have to be supplied with the input data somehow. Either we have to use a custom executable that is compiled at build time. In that case we would just get rid of the std::cout << ... in the C++ code, but not much else would change. The other option is to use the default mustache executable, which is a Ruby script and therefore requires Ruby to be installed.

Also kdb gen cannot be reused, since that would require compiling kdb first, which needs kdberrors.h.

Why not option 3?

Generating the C code might work in CMake, but more complex languages might have problems with using CMake.

If we do decide to use some form of code-generation, we should only generate the parts that absolutely need to be generated. For example the current kdberrors.h contains a lot of code that is completely static and independent of which errors we actually have. This code shouldn't be generated, we should #include it from a static file.

I also prefer option 1 because of stable error codes. Adding code generation also adds unnecessary complexity to the overall code which is again error prone.

@kodebach thank you for your elaboration on option 2

I think it is quite clear that we go for option 1, @Piankero can you please write up the decision?

For the bindings it means that not much changes.

What would be great if we had a binding writing tutorial, describing:

1. which parts of Elektra bindings make sense (application, plugin, tools, ...)
2. how to integrate bindings into CMake (if possible and useful)
3. which parts of the bindings can and should differ for every language. This includes:
   
   
   
   • iterators
   
   
   • conversion to native types (strings, int, ...)
   
   
   • operator overloading (if available)
   
   
   • other programming language integrations (streams, hash-codes, identity, ...)
   
   
   • returned errors from kdb functions (what this issue here is about)
   
   

I hope we can extend this tutorial for the different situations we see in different languages. @Piankero can you please start to write the tutorial, in particular the error handling section (how to implement inheritance, ...)

Tutorial: #2875
Design Decision: #2872