decide intended usage

[3b]

a few combinations to consider

• full "projection" (nice wrappers as main API, hide details where possible, etc)
  The metadata provides lots of useful things to allow automatic generation of "nice" APIs:
  • which function to use to release various return values
  • which arguments are reserved and should be 0 (so can be skipped in wrapped API)
  • which argument/field shows size or count of elements in an array
  • fields that must be initialized to size of struct
• low-level direct C-like bindings (pointers, manual resource management etc)
  Easier to generate, but harder to use. Good enough for a lot of simple things though. Probably can get close enough to the 'nice' api for a lot of slightly more complicated things by generating with-foo macros.

and orthogonal to that:

• Generate entire FFI at once (probably as a bunch of separate systems so people don't have to download everything at once).
  Probably easier, since it doesn't require the parser/generator code to be reliable enough for general use, but also leads to shipping a big pile of untested code, and not sure how much overhead compiling/loading unused FFI definitions would add.
• API to let users generate just the FFI they need and put it directly into their project.
  More work since the parser/generator needs to be more reliable and more configurable. Savings from generating just what you need might in practice be lost if dependencies also needed the same thing and you ended up with multiple copies (or more work to avoid the duplication).