Klemens Böswirth

@markus2330 Can we agree on this approach? > 1. Public headers live in `include/elektra/[libname]` > 2. Private headers live next to the source files in e.g. `src/libs/core-c/` or `src/libs/kdb`. >...

> how can we check and enforce such a rule? Writing a script (maybe using clang-query) to run as a test case and in CI should be easy enough. As...

Sadly using `clang-query` doesn't work, since the Clang AST doesn't contain any nodes for preprocessor directives. But I checked against a `tree-sitter` query (tree-sitter's grammar has nodes for preprocessor directives),...

@markus2330 The decisions are now updated, please review again.

> We should avoid further whitelisting mechanisms. Wouldn't it be possible to write it differently to not trigger a false positive? AFAICT with our formatting rules there shouldn't be any...

@markus2330 Let's move the discussion about "unstable" API from #4245 to this PR, since it also affects the header structure. I have thought about it some more and I came...

> Maybe we can get all functions in the important libraries non-experimental, and I think everyone agrees that this would be the best. Yes, but I'd like to finish this...

> What is missing? The PR doesn't seem updated. I wanted to know, if you agree with the ideas about "internal" headers from this comment https://github.com/ElektraInitiative/libelektra/pull/4246#issuecomment-1249185666. If so, I will...

> Furthermore, urgent now is merging new-backend. I don't see a correlation of these decisions and the work on new-backend. Yes, I know you want to merge `new-backend`. But I...

Okay, so we do agree after all. I'll update the files in this PR, when I have some spare time.