Ideas

[mara004]

• Improved support for binding to python API.
• Inline-define preamble helpers separately and embed on demand; make c_ptrdiff_t a dependency node and include only as needed
• Add opt-in autostrings helper with configurable codec, see draft
• Merge preamble helpers and loader into a single file (to simplify printer) ? -> problem: headers-only build does not need libraryloader
• 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 lead to the same result 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.