Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

code generation for errors #2871

Open
markus2330 opened this issue Aug 11, 2019 · 4 comments

Comments

@markus2330
Copy link
Contributor

commented Aug 11, 2019

In the previous error concept it was very useful to generate macros as we often added new errors. The code generation itself, however, is quite complicated (C++ code that prints the code; which is also not ideal for cross compilation, see also #2814).

Now we have a more or less fixed set of a few errors. So the question is what we should do:

  1. write down the few macros manually (make kdberrors.h static, maybe also including #2697), and also manually write down exceptions for the language bindings (and also the mappings from Elektra's internal errors to nice errors specific for the languages)
  2. migrate to a more modern and easier way to generate code with our mustache system, and let this generate the (mapping) code for all compiled languages (C, C++, Java, Rust, Go).
  3. migrate to CMake code that generates such macros/classes (see also #2814)

@PhilippGackstatter @raphi011 @kodebach @Piankero What do you think?

@kodebach

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2019

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.

@Piankero

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2019

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.

@markus2330

This comment has been minimized.

Copy link
Contributor Author

commented Aug 11, 2019

@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, ...)

@Piankero

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

Tutorial: #2875
Design Decision: #2872

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.