In the 14.5 (!) years I've been maintaining the Derelict bindings, I've restructured the source tree a few times (Derelict 1 - 3 to DerelictOrg), had three implementations of the loader (that I can remember), switched from Subversion to Git, and supported a few different approaches to building (bud, dss, Visual D projects, a couple of custom scripts) before finally settling exclusively DUB.

Along the way, my approach to the overall architecture has become a headache to maintain and a more confusing than it needs to be for users to know which version of a binding they need for a given C library version. Moreover, the loader as implemented now is not usable in -betterC mode, is only partially @nogc, and is not nothrow at all. And I've never once had a full set of documentation for any iteration of Derelict.

When I sat down to see how I could rectify those issues, I decided it's time for Derelict to ride off into the sunset. Better just to start an entirely new project. I immediately saw an obvious way (that I couldn't believe I had missed before) to ease my maintenance burden while also making it easier for users to match the bindings with specific versions of the C libraries.

Everything is configurable at compile time, including which version of a C library you'd like to bind to. Most of the packages will have both dynamic and static versions. The loader is compatible with -betterC (not enabled by default) and is 100% @nogc and nothrow. No more pain for me when updating a package to support new C library versions. No more worries about matching up Derelict package versions with C library versions and git branches.

I first implemented the loader and the SDL binding a few months back. Since that time, dpp has been announced. Before anyone asks me why they should use BindBC over dpp, let me just give you my answer: You shouldn't.

What I mean is, I don't care if you use BindBC or not. It's there if you want it. dpp almost completely kills the reason to use any BindBC package in its static binding configuration. The only marginal benefit BindBC provides as a static binding is that you don't need to add dpp to your workflow or worry about the C headers. Using dpp to generate the binding for you means you can always be up to date, and accurate, with the latest version of the C library, you don't have to wait on me, and you don't have to worry about my typos.

Aside from that, if you find you need or want a dynamic binding where you don't need to worry about link-time dependencies and the shared libraries are loaded at run time, then BindBC and Derelict are the only games in town. I don't recommend Derelict for new projects unless you need a binding I haven't ported over yet.

Currently, all of the Derelict packages in DerelictORG that I maintain (I can't speak for Guillaume) can be considered in limited maintenance mode. I'll fix bugs, but I have no plans to update any of the bindings to the latest C libraries unless someone absolutely, positively can't live without it.

I plan to port the more used Derelict bindings over the course of the next few weeks. I've got another massive project I'm working on that will make use of some of the BindBC packages, so I'll be focusing first on the ones I need for that.

Currently ported:

bindbc-sdl (includes SDL_image, SDL_mixer, and SDL_ttf)
https://github.com/BindBC/bindbc-sdl
http://bindbc-sdl.dub.pm/

bindbc-glfw
https://github.com/BindBC/bindbc-glfw
http://bindbc-glfw.dub.pm/

bindbc-opengl
https://github.com/BindBC/bindbc-opengl
http://bindbc-opengl.dub.pm/

The README for each project should have all you need to know to use each binding. Be sure to READ FIRST if you do use them.

Anyone who would like to port their one Derelict bindings over can use the bindbc-loader package to do the loading. I have no documentation yet on how you should structure a BindBC binding, but it isn't hard to derive from the existing packages. Look at the READMEs and the source code for inspiration.

https://github.com/BindBC/bindbc-loader
http://bindbc-loader.dub.pm/

On Friday, 19 October 2018 at 17:34:10 UTC, Mike Parker wrote:
> [...]

When I saw the packages appearing on dub, I knew an announcement was imminent. This is great stuff!

I don't think dpp obsoletes this. If you aren't already using dpp, being able to just add a dependency from dub is less of a barrier than keeping a C header and incorporating d++ and .dpp files in your project.

On Friday, 19 October 2018 at 17:34:10 UTC, Mike Parker wrote:
> dpp almost completely kills the reason to use any BindBC package in its static binding configuration. The

I've used the OpenGL and GLFW BindBC bindings for a few days or so now, and its certainly a lot more convenient to use that dpp...

I really like that you can load whatever version of a lib is present and act accordingly - for example if only OpenGL 3v3 is available or OpenGL 4v5 you can configure your renderer accordingly

There is also great feedback when something goes wrong, great if someone reports a bug in your app...

On Friday, 19 October 2018 at 17:34:10 UTC, Mike Parker wrote:
> In the 14.5 (!) years I've been maintaining the Derelict bindings, I've restructured the source tree a few times (Derelict 1 - 3 to DerelictOrg), had three implementations of the loader (that I can remember), switched from Subversion to Git, and supported a few different approaches to building (bud, dss, Visual D projects, a couple of custom scripts) before finally settling exclusively DUB.
>
> [...]

Great Stuff! Thank you very much!

On Friday, 19 October 2018 at 17:34:10 UTC, Mike Parker wrote:
>
> I plan to port the more used Derelict bindings over the course of the next few weeks. I've got another massive project I'm working on that will make use of some of the BindBC packages, so I'll be focusing first on the ones I need for that.
>

Unfortunately it's unlikely I will have the time to port:
- DerelictBgfx
- DerelictENet
- DerelictCUDA

to BindBC so they are also in limited maintenance mode.

So I'm looking for someone to take ownership of those libraries!


BindBC is great news regardless for those of us without runtime or in -betterC! We use a derelict-util fork to this effect until now.

On Friday, 19 October 2018 at 17:34:10 UTC, Mike Parker wrote:
> [...]

Well done!

On Friday, 19 October 2018 at 17:34:10 UTC, Mike Parker wrote:
> In the 14.5 (!) years I've been maintaining the Derelict bindings, I've restructured the source tree a few times (Derelict 1 - 3 to DerelictOrg), had three implementations of the loader (that I can remember), switched from Subversion to Git, and supported a few different approaches to building (bud, dss, Visual D projects, a couple of custom scripts) before finally settling exclusively DUB.
>
> [...]

Hey Mike,

Nice work on the new loader, I'm a big user of the Derelict loader, and I agree that having a betterC / @nogc loader is a big win, so thanks in advance for working on it.

Which libraries are going to be supported ? In my current project I use the following Derelict bindings:

derelict-al
derelict-alure
derelict-vorbis
derelict-lua

Will these be ported to BindBC eventually ?

Thanks for the effort in maintaining Derelict for so long.

Danny

On Tuesday, 30 October 2018 at 12:17:52 UTC, Danny Arends wrote:

>
> Nice work on the new loader, I'm a big user of the Derelict loader, and I agree that having a betterC / @nogc loader is a big win, so thanks in advance for working on it.
>
> Which libraries are going to be supported ? In my current project I use the following Derelict bindings:
>
> derelict-al
> derelict-alure
> derelict-vorbis
> derelict-lua
>
> Will these be ported to BindBC eventually ?
>
> Thanks for the effort in maintaining Derelict for so long.
>
> Danny

Thanks! Yes, I'll port all of those over. I implemented most of bindbc-al the other day. I plan to sit down and finish it up later this week. Be forewarned though, my plans too frequently have a mind of their own.

On Tuesday, 30 October 2018 at 12:35:15 UTC, Mike Parker wrote:
> Thanks! Yes, I'll port all of those over. I implemented most of bindbc-al the other day. I plan to sit down and finish it up later this week. Be forewarned though, my plans too frequently have a mind of their own.

Mike could you add those of us who are members of derelict to BindBC? I'll take a look at porting CUDA and OpenCL over to BindBC.

Thanks
Nic