BindBC codegen survey (page 2)

On Saturday, 23 August 2025 at 15:35:30 UTC, IchorDev wrote: > 2. Have you ever experienced any usability issues caused by the automatic code-generation in a BindBC library? The last time I’ve used them, DCD had quite a hard time comprehending them.

1 day ago

Re: BindBC codegen survey

Posted by Luna
in reply to Luna

Permalink

Luna

Posted in reply to Luna

Permalink

On Tuesday, 9 September 2025 at 02:33:56 UTC, Luna wrote:

On Sunday, 31 August 2025 at 11:12:42 UTC, IchorDev wrote:

On Monday, 25 August 2025 at 13:01:08 UTC, Luna wrote:

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.

I’ll add that I do plan to write tooling to help convert some of the more common C and C++ documentation formats to DDOC; and potentially also some way to map Objective-C classes to Apple’s online documentation to extract from that. As well as a way to generate sphinx documentation pages from ddoc for use with ReadTheDocs.

I’ll make a post on the forums when that tooling is ready.

On Tuesday, 9 September 2025 at 02:33:56 UTC, Luna wrote:

On Sunday, 31 August 2025 at 11:12:42 UTC, IchorDev wrote:

Only infeasible if the projects don’t provide documentation [...]

I don't think you understood. BindBC projects usually support various different versions of a library. Over the course of many updates, a library's documentation often changes in ways that make it manifestly incompatible with older versions. For instance, when working on SDL2, I noticed that some functions and parameters had become obsolete over time, and the documentation reflected this. For projects that have frequent breaking changes, this problem can be even more complicated.

> > >

constant version incompatibilities, slower compile times

Could you please elaborate on these two?

I don't think I ever updated the BindBC-Loader minor dependency version in a patch release. I might have missed updating some packages to use the latest BindBC-Loader for a while at some point, but that would be the time to create an issue.
These days almost all of the libraries use "bindbc-loader": "~>1.1", so if I incremented the minor version of BindBC-Loader again it wouldn't cause the same problem this time, and you could even keep using the older BindBC-Loader version.

And what about compile times? Do you have any profiling results you could show?

Forums