digitalmars.D - BindBC codegen survey
- IchorDev (16/16) Aug 23 Dear BindBC users,
- Jordan Wilson (8/24) Aug 23 1. bindbc-allegro5, and bindbc-physfs
- Guillaume Piolat (5/5) Aug 24 1. bindbc-sdl
- IchorDev (24/28) Aug 25 Unfortunately these are unofficial packages that I have no direct
- IchorDev (24/28) Aug 25 Unfortunately these are unofficial packages that I have no direct
- Ogion (8/11) Sep 02 I considered using wrappers but was concerned about possible
- Jordan Wilson (4/8) Sep 04 Yeah, not having to use `gendef/dlltool` to generate import lib
- IchorDev (4/8) Sep 05 The compile-time linker errors are usually easier to understand,
- Luna (9/25) Aug 25 1. bindbc-opengl is the only remaining dependency, used to use
- IchorDev (7/9) Aug 31 What kind of documentation would there be?
- Mike Shah (7/13) Aug 25 bindbc.sdl and bindbc.opengl (and I by extension, bindbc.loader).
- IchorDev (2/5) Aug 31 Oh hey, that sounds awesome!
- 0xEAB (3/5) Sep 05 The last time I’ve used them, DCD had quite a hard time
Dear BindBC users, I am conducting an informal survey on the forums here to gauge the impact of the project's wide adoption of automatic code-generation via string mixins over the past 4 years. If you depend on one or more BindBC libraries in your project, then I would love if you could fill out your answers to the following questions, particularly noting which specific libraries affected your answers & when you had this experience. Your answers will help inform what direction I take for the future of the BindBC project's code. 1. What BindBC libraries do your projects depend on, and to what extent do you rely on them? 2. Have you ever experienced any usability issues caused by the automatic code-generation in a BindBC library? 3. Have you ever found that a BindBC library took a long time to compile?
Aug 23
On Saturday, 23 August 2025 at 15:35:30 UTC, IchorDev wrote:Dear BindBC users, I am conducting an informal survey on the forums here to gauge the impact of the project's wide adoption of automatic code-generation via string mixins over the past 4 years. If you depend on one or more BindBC libraries in your project, then I would love if you could fill out your answers to the following questions, particularly noting which specific libraries affected your answers & when you had this experience. Your answers will help inform what direction I take for the future of the BindBC project's code. 1. What BindBC libraries do your projects depend on, and to what extent do you rely on them? 2. Have you ever experienced any usability issues caused by the automatic code-generation in a BindBC library? 3. Have you ever found that a BindBC library took a long time to compile?1. bindbc-allegro5, and bindbc-physfs 2. Haven't noticed any issues. Hmmm maybe optional parentheses don't appear to be optionally anymore? I noticed this going from `SiegeLord/DAllegro5` to `bindbc-allegro5`. 3. No Not sure if this is helpful at all, but anyway... Jordan
Aug 23
Guillaume Piolat <first.nam_e gmail.com> 1. bindbc-sdl 2. No, however bindbc always build in separate packages even --combined, not sure why. 3. Not remakerd anything. Of course more speed is always appreciated.
Aug 24
On Saturday, 23 August 2025 at 20:53:47 UTC, Jordan Wilson wrote:1. bindbc-allegro5, and bindbc-physfsUnfortunately these are unofficial packages that I have no direct control over.2. Haven't noticed any issues. Hmmm maybe optional parentheses don't appear to be optionally anymore? I noticed this going from `SiegeLord/DAllegro5` to `bindbc-allegro5`.That would be because you are using dynamic bindings. `bindbc-allegro5` doesn't wrap its function pointers in a regular function (most official BindBC libraries do this now), and functions vs function pointers have incompatible call/reference syntax: ```d int fn(){} //a function int function() fnPtr; //a function pointer int a1 = fn(); int a2 = fnPtr(); int b1 = fn; int function() b2 = fnPtr; int function() c1 = &fn; int function()* c2 = &fnPtr; ``` `SiegeLord/DAllegro5` only has static bindings, but `bindbc-allegro5` defaults to using dynamic bindings. For most use-cases static bindings are simpler. Dynamic bindings are useful when you seriously need to re-link libraries at runtime (i.e. basically never), or want more control over 'missing library' error messages for a better end-user experience.
Aug 25
On Saturday, 23 August 2025 at 20:53:47 UTC, Jordan Wilson wrote:1. bindbc-allegro5, and bindbc-physfsUnfortunately these are unofficial packages that I have no direct control over.2. Haven't noticed any issues. Hmmm maybe optional parentheses don't appear to be optionally anymore? I noticed this going from `SiegeLord/DAllegro5` to `bindbc-allegro5`.That would be because you are using dynamic bindings. `bindbc-allegro5` doesn't wrap its function pointers in a regular function (most official BindBC libraries do this now), and functions vs function pointers have incompatible call/reference syntax: ```d int fn(){} //a function int function() fnPtr; //a function pointer int a1 = fn(); int a2 = fnPtr(); int b1 = fn; int function() b2 = fnPtr; int function() c1 = &fn; int function()* c2 = &fnPtr; ``` `SiegeLord/DAllegro5` only has static bindings, but `bindbc-allegro5` defaults to using dynamic bindings. For most use-cases static bindings are simpler. Dynamic bindings are useful when you seriously need to re-link libraries at runtime (i.e. basically never), or want more control over 'missing library' error messages for a better end-user experience.
Aug 25
I’m the developer of BindBC-Allegro5. On Monday, 25 August 2025 at 10:40:18 UTC, IchorDev wrote:`bindbc-allegro5` doesn't wrap its function pointers in a regular function (most official BindBC libraries do this now)I considered using wrappers but was concerned about possible performance impact on debug builds. The overhead of uninlined wrappers in hot parts of code is not negligible.For most use-cases static bindings are simpler.Static bindings have a compile-time dependency on the dynamic/import libraries. I’d say that dynamic bindings are simpler for a casual user.
Sep 02
On Tuesday, 2 September 2025 at 10:41:30 UTC, Ogion wrote:Yeah, not having to use `gendef/dlltool` to generate import lib is nice. JordanFor most use-cases static bindings are simpler.Static bindings have a compile-time dependency on the dynamic/import libraries. I’d say that dynamic bindings are simpler for a casual user.
Sep 04
On Tuesday, 2 September 2025 at 10:41:30 UTC, Ogion wrote:The compile-time linker errors are usually easier to understand, if you ask me. They also don't require the user to write any code to find out what's going wrong.For most use-cases static bindings are simpler.Static bindings have a compile-time dependency on the dynamic/import libraries. I’d say that dynamic bindings are simpler for a casual user.
Sep 05
On Saturday, 23 August 2025 at 15:35:30 UTC, IchorDev wrote:Dear BindBC users, I am conducting an informal survey on the forums here to gauge the impact of the project's wide adoption of automatic code-generation via string mixins over the past 4 years. If you depend on one or more BindBC libraries in your project, then I would love if you could fill out your answers to the following questions, particularly noting which specific libraries affected your answers & when you had this experience. Your answers will help inform what direction I take for the future of the BindBC project's code. 1. What BindBC libraries do your projects depend on, and to what extent do you rely on them? 2. Have you ever experienced any usability issues caused by the automatic code-generation in a BindBC library? 3. Have you ever found that a BindBC library took a long time to compile?1. bindbc-opengl is the only remaining dependency, used to use bindbc for all bindings, moved away. 2. Poor to no documentation, constant version incompatibilities, slower compile times and overall difficult to inspect code lead me to drop bindbc. 3. Yes, mainly bindbc-opengl, though some of this was due to compiler quirks. However the other usability issues are mainly what made me drop it.
Aug 25
On Monday, 25 August 2025 at 13:01:08 UTC, Luna wrote:2. Poor to no documentationWhat 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.constant version incompatibilities, slower compile timesCould you please elaborate on these two?
Aug 31
On Sunday, 31 August 2025 at 11:12:42 UTC, IchorDev wrote:On Monday, 25 August 2025 at 13:01:08 UTC, Luna wrote: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.2. Poor to no documentationWhat 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.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.constant version incompatibilities, slower compile timesCould you please elaborate on these two?
Sep 08
On Tuesday, 9 September 2025 at 02:33:56 UTC, Luna wrote:On Sunday, 31 August 2025 at 11:12:42 UTC, IchorDev wrote: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 Monday, 25 August 2025 at 13:01:08 UTC, Luna wrote: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.2. Poor to no documentationWhat 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.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.constant version incompatibilities, slower compile timesCould you please elaborate on these two?
Sep 08
On Tuesday, 9 September 2025 at 02:33:56 UTC, Luna wrote:On Sunday, 31 August 2025 at 11:12:42 UTC, IchorDev wrote: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.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 [...]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?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. [...] Solving this would require locking dependencies for x.y.0constant version incompatibilities, slower compile timesCould you please elaborate on these two?
Sep 09
On Saturday, 23 August 2025 at 15:35:30 UTC, IchorDev wrote:1. What BindBC libraries do your projects depend on, and to what extent do you rely on them?bindbc.sdl and bindbc.opengl (and I by extension, bindbc.loader). I've been using these for teaching students graphics and games courses on windows, linux, and mac.2. Have you ever experienced any usability issues caused by the automatic code-generation in a BindBC library?Not so far.3. Have you ever found that a BindBC library took a long time to compile?I haven't profiled, so it's been fast enough for the smaller scale projects I've worked on.
Aug 25
On Monday, 25 August 2025 at 17:22:40 UTC, Mike Shah wrote:bindbc.sdl and bindbc.opengl (and I by extension, bindbc.loader). I've been using these for teaching students graphics and games courses on windows, linux, and mac.Oh hey, that sounds awesome!
Aug 31
On Sunday, 31 August 2025 at 11:07:39 UTC, IchorDev wrote:On Monday, 25 August 2025 at 17:22:40 UTC, Mike Shah wrote:One small update, that I have started making videos in my SDL3 series with Dlang to show how to setup (in some of them) bindbc.sdl. This may be useful documentation for folks :) https://www.youtube.com/playlist?list=PLvv0ScY6vfd-5hY-sFyttTjfuUxG5c7OAbindbc.sdl and bindbc.opengl (and I by extension, bindbc.loader). I've been using these for teaching students graphics and games courses on windows, linux, and mac.Oh hey, that sounds awesome!
Sep 09
On Tuesday, 9 September 2025 at 22:42:29 UTC, Mike Shah wrote:On Sunday, 31 August 2025 at 11:07:39 UTC, IchorDev wrote:Wow, that's so cool! :) I noticed at [11:10 in Episode 2.1](https://youtu.be/V7BNGMX7U9I?t=670): you say 'you can decide if you want to link statically', but this might be misleading. The option you're referring to actually enables static *bindings*. It's a common misconception, but static *bindings* ≠ static *linking*: - **Dynamic bindings**: only support dynamic *linking* (since the library is loaded by your code) - **Static bindings**: can be either statically *linked* **or** dynamically *linked*. If they're dynamically linked, then the compiler generates its own library loading code and runs it before your code is ever called into. You can read more about static bindings [here](https://git.sleeping.town/BindBC/bindbc-sdl#static-bindings) in BindBC-SDL's readme.Oh hey, that sounds awesome!One small update, that I have started making videos in my SDL3 series with Dlang to show how to setup (in some of them) bindbc.sdl. This may be useful documentation for folks :) https://www.youtube.com/playlist?list=PLvv0ScY6vfd-5hY-sFyttTjfuUxG5c7OA
Sep 10
On Wednesday, 10 September 2025 at 10:42:49 UTC, IchorDev wrote:On Tuesday, 9 September 2025 at 22:42:29 UTC, Mike Shah wrote:Good catch! Thank you for pointing me to the right resources 👍👍[...]Wow, that's so cool! :) I noticed at [11:10 in Episode 2.1](https://youtu.be/V7BNGMX7U9I?t=670): you say 'you can decide if you want to link statically', but this might be misleading. The option you're referring to actually enables static *bindings*. It's a common misconception, but static *bindings* ≠ static *linking*: - **Dynamic bindings**: only support dynamic *linking* (since the library is loaded by your code) - **Static bindings**: can be either statically *linked* **or** dynamically *linked*. If they're dynamically linked, then the compiler generates its own library loading code and runs it before your code is ever called into. [...]
Sep 10
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.
Sep 05