BindBC codegen survey

[Luna]

On Sunday, 31 August 2025 at 11:12:42 UTC, IchorDev wrote:
> On Monday, 25 August 2025 at 13:01:08 UTC, Luna wrote:
>> 2. Poor to no documentation
>
> What kind of documentation would there be?
> If you mean documentation from the original project the 
> bindings are for, then this is simply infeasible due to 
> requiring an astronomical amount of time to convert, and the 
> potential for documentation to be different between versions, 
> etc.

Only infeasible if the projects don’t provide documentation, 
otherwise it would be best to hand write these bindings with 
documentation hand converted to ddoc, or write tooling to 
automate it. It’s tedious but long term worth it that you can 
have documentation at your fingertips instead of 30 browser tabs 
open after 10 minutes of coding.

>> constant version incompatibilities, slower compile times
> 
> Could you please elaborate on these two?

Often I’ve used the ~> version identifier, but occasionally 
you’ve updated the loader implementation, then updated one 
library to use it and not another, while the patch releases end 
up dependency incompatible. Mostly dealt with this in 
bindbc-opengl and bindbc-sdl. Has made building my projects 
difficult for some as suddenly a new x.y.z release is out for sdl 
that is incompatible with the latest x.y.z opengl package.

Solving this would require locking dependencies for x.y.0 so that 
those point releases don’t end up with incompatible bindbc 
loaders. Then seeing dependency updates as a breaking change that 
neccesitates a bump of x.y version number.