www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - BindBC -- The successor to Derelict

reply Mike Parker <aldacron gmail.com> writes:
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/
Oct 19 2018
next sibling parent Dennis <dkorpel gmail.com> writes:
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.
Oct 19 2018
prev sibling next sibling parent Codifies <a b.com> writes:
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...
Oct 19 2018
prev sibling next sibling parent SrMordred <patric.dexheimer gmail.com> writes:
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!
Oct 19 2018
prev sibling next sibling parent Guillaume Piolat <spam smam.org> writes:
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.
Oct 20 2018
prev sibling next sibling parent Andrea Fontana <nospam example.com> writes:
On Friday, 19 October 2018 at 17:34:10 UTC, Mike Parker wrote:

 [...]


Well done!
Oct 21 2018
prev sibling parent reply Danny Arends <Danny.Arends gmail.com> writes:
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
Oct 30 2018
parent reply Mike Parker <aldacron gmail.com> writes:
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.
Oct 30 2018
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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
Oct 30 2018