BindBC -- The successor to Derelict

Mike Parker aldacron at gmail.com
Fri Oct 19 17:34:10 UTC 2018


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/




More information about the Digitalmars-d-announce mailing list