Ideas

[mara004]

• Improve support for binding to python API.
• Inline-define preamble helpers separately and embed on demand
• Add opt-in autostrings helper with configurable codec, see draft
• Restore multilib support through CLI groups?, see draft
• Consider replacing --all-headers with --deepen [N]. Behave like --all-headers if the flag is specified without value, but allow e.g for --deepen 1 to eagerly add members from one nesting only, and not the whole include tree (which might be the most common case to currently use --all-headers).
  Discourage full-depth inclusion (as this tends to spam the bindings and pull in problematic macros) -- instead suggest explicit --symbol-rules yes=....
  (Fun fact: --symbol-rules yes=.+ should have the same effect as --all-headers)
• Add second CLI entrypoint allowing to bind to each input header individually, as a higher-level layer around current capabilities, i.e. automatic header dependency tree resolution and module linking (within one library). Advantages: namespace separation, closer to original C library.
• Add PYI printer?; allow specifying multiple printers at once to avoid repeating common pipeline steps

[mara004]

Question to self: What happens when members from shared headers are shadowed?
e.g. a shared header defining foo() but an includee overriding it with a different definition?
I believe this will be a case where module linking would currently miss the override...
(Update from investigation: I think the conflicting names resolver would currently add an underscore to the overriding member.)
A possible approach might be to check the symbol's source file.