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.

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?

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

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.)

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)?

Thank you,

olivier

Reply via email to