Kdb rewrite cpp spec

[hannes99]

Basics

Adds spec for cpp commands, so help/error messages are now generated by opts for both C and C++ commands. Nothing else really happens in this PR, except that cmerge -> merge.

• Short descriptions of your changes are in the release notes
  (added as entry in doc/news/_preparation_next_release.md which contains _(my name)_)
  Please always add them to the release notes.
• Details of what you changed are in commit messages
  (first line should have module: short statement syntax)
• References to issues, e.g. close #X, are in the commit messages.
• The buildservers are happy. If not, fix in this order:
  • add a line in doc/news/_preparation_next_release.md
  • reformat the code with scripts/dev/reformat-all
  • make all unit tests pass
  • fix all memleaks
  • fix the CI itself (or rebase if already fixed)
• The PR is rebased with current master.

Checklist

• I added unit tests for my code
• I fully described what my PR does in the documentation
  (not in the PR description)
• I fixed all affected documentation (see Documentation Guidelines)
• I fixed all affected decisions (see Decision Process)
• I added code comments, logging, and assertions as appropriate (see Coding Guidelines)
• I updated all meta data (e.g. README.md of plugins and METADATA.ini)
• I mentioned every code not directly written by me in reuse syntax

Review

• Documentation is introductory, concise, good to read and describes everything what the PR does
• Examples are well chosen and understandable
• Code is conforming to our Coding Guidelines
• APIs are conforming to our Design Guidelines
• Code is consistent to our Design Decisions

Labels

• Add the "work in progress" label if you do not want the PR to be reviewed yet.
• Add the "ready to merge" label if everything is done and no further pushes are planned by you.

[kodebach]

Very nice. A clean simple solution for including the C++ code.

For the docs: We know prefer one sentence per line for new/updated docs (see here). I know many old docs are not written like this, so it can be easy to ignore this and follow the existing style in a file. But the new style really makes diffs easier to read, especially for small changes.

Otherwise, mostly questions and small suggestions. Nothing that really needs to change for a merge IMO.

One small but really nice addition would also be, if you added a KDB_WITHOUT_CPP CMake variable. Which would exclude all C++ files from kdb together with something like this in the main.c:

#ifdef KDB_WITHOUT_CPP
cppCommand cppSubcommands[] = {};
#else
cppCommand cppSubcommands[] = {
   // ... actual commands ...
};
#endif

Alternatively, KDB_WITHOUT_CPP could include a dummy .c which defines cpp_main as a function that just prints "C++ not included". Then it would actually be possible to build kdb without C++ (I think).

[hannes99]

Thanks for the feedback!

[hannes99]

jenkins build libelektra please

[hannes99]

jenkins build libelektra please

[kodebach]

LGTM now