Currently we pre-build bindings.rs against a specific flipperzero-firmware release. While it's worked reasonably well, it does have some issues:

• Only a single major SDK version is supported by the crate (there are still regular API breaks, even after 1.0.1)
• Only a single target (f7) is supported by the crate, even though there is work on a newer targets upstream (e.g. f18)
• While not the main focus of this crate, this approach is incompatible with alternate firmwares (often with incompatible SDK ABI)
• The provenance of bindings.rs isn't easily to determine (though ci: enable automatic SDK Update PR creation #152 significantly improves the situation)

There's a couple of possible approaches that come to mind:

• Provide multiple versions of bindings.rs, targeting several SDK / target combinations
• Perform generation of SDK bindings on the fly (allowing user to specify the SDK / target via environment variable)
• Require user to explicitly provide an SDK (via environment variable)