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/
