DerelictBgfx not shipping core libs.

Thu Nov 6 04:31:32 PST 2014

On 11/6/2014 3:44 PM, olivier henley wrote:
> Hi,
>
> May I ask what is the rational to not ship the core libs with the bgfx D
> wrapper? From my point of view it defies the main goal of using a D
> wrapper.

First, let's get some terminology straight. There are no "wrappers" in 
Derelict. The Derelict packages are all "bindings," meaning they are 
one-to-one translations (as much as possible) of the original library. A 
wrapper is something that provides functionality on top of the binding 
and makes it more like the host language.

As the guy who created Derelict in the first place, I can give you a 
simple rationale behind not distributing the binaries -- it is not my 
responsibility. I'll give you three even better reasons now :)

If I start shipping the C shared libraries for every binding in 
Derelict, then,

1) I must consider all supported platforms (Windows, Mac, Linux, 
FreeBSD, OpenBSD, and wherever people are using GDC and LDC these days). 
Would I be expected to provide prebuilt binaries for each platform?

2) I must also consider the multiple options each library can be 
configured to support. For example, the Open Dynamics Engine (to which 
DerelictODE binds) can be compiled to use doubles or floats. Would I be 
expected to provide prebuilt binaries for each?

3) In order to support 1 and 2 above, I would then have to make time to 
either compile or acquire pre-built binaries for each supported platform 
and each compile time configuration for each C library to which Derelict 
binds. To that I say, no thanks.

> 1. How can we promote the wrapper package if it implies to build not
> one, as of ... only bgfx, but two packages, bgfx and DerelictBgfx?
> Better stick to c/c++ then, and enjoy the path of least resistance.
> Don't you think?

I've been maintaining Derelict for 10 years. In all that time, you are 
the first person to ever bring this up that I've seen. That tells me 
that it's a non-issue.

Some C library projects provide prebuilt binaries, some don't. It's 
entirely up to you to learn what you need to know about the libraries 
you need to use, including how to get them. Derelict just enables access.

>
> 2. Does the maintainer guaranty his wrapper will stay in sync with
> further changes of bgfx?

ponce is the primary maintainer of DerelictBGFX and has provided his own 
answer, but I would add that anyone can post a pull request to github 
for any of the binding packages in DerelictOrg, including the Bgfx 
binding. Or, at the very least, create an issue with a request to 
update. So if any of them fall behind, it's an easy problem to solve. 
Since I moved Derelict to github a few years back, keeping everything up 
to date has been smooth sailing.

>
> 3. Is there anything in the license refraining from shipping precompiled
> libs of the original package? (e.g. To my knowledge tkd publishes
> similar binaries (tcl and tk) without further legal complications.)

The answer to this is no, but it's irrelevant.

>
> 4. Am I missing something except the fact that a neophyte to the
> DerelictBgfx package is left with an incomplete build, of both the lib
> and the examples, an anemic README.md and a dead forum
> (http://dblog.aldacron.net/forum/index.php?topic=841.0)?

It is not an incomplete build. It provides everything it is supposed to. 
The Derelict bindings enable you to use C libraries in D, and nothing 
more. If you need examples on how to use Bgfx, you need to be talking to 
the Bgfx maintainer (you can find the link in the first line of the 
README). Everything you need to know to use DerelictBGFX is right there 
in the anemic README. The forum link shouldn't be there and should have 
been replaced with a link to [1]. When I was updating all of the READMEs 
to point to the new location, I overlooked ponce's bindings and no one 
had reported it. That one's on me.

I'm working on a comprehensive set of documentation for all Derelict 
packages [2] that will be more friendly to those who aren't sure what's 
going on, but it is not going to be a tutorial on compiling C libraries, 
nor will it provide examples on how to use any of the C libraries it 
binds to. That's well beyond the scope of the project. At present, there 
is enough there to supersede the page at [1] and to replace the 
information from the dead forum link. All of the Derelict READMEs will 
eventually point to it when it is complete.

[1] http://dblog.aldacron.net/derelict-help/using-derelict/
[2] http://derelictorg.github.io/