Hi,
First, I'd like to point out this question is better asked in
DerelictBgfx issues or digitalmars.D.learn, this NG is for
general D discussion.
On Thursday, 6 November 2014 at 06:44:49 UTC, 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.
Shipping binaries with FFI bindings defeats software distribution.
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 know this is annoying, but for others dynamic libraries
binaries are provided.
You might ask for bgfx to provide you with binaries with
automated builds.
For other libraries, you will find that D is the path of least
resistance (try using GLEW in C++ vs DerelictGL3 in D, the latter
is easier).
2. Does the maintainer guaranty his wrapper will stay in sync
with further changes of bgfx?
I'm afraid, my plate is already full.
bgfx interface changes without notice and frequently.
You can still build an older version.
That said, two times people have come up and updated the bindings
already.
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.)
I feel like this is a responsibility of bgfx to provide binaries.
DerelictSDL does not come with SDL binaries likewise, that would
be insane.
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)?
I guess I should add in the README that you have to build bgfx
yourself for time being to avoid being let down.
