On Thursday, 6 November 2014 at 08:17:24 UTC, ponce wrote:
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.
Not agree. DerelictBgfx is one of the most interesting project D
has to show off and therefore its usability becomes, IMHO, of
general interest. Showing off is what makes the world turn so ...
Shipping binaries with FFI bindings defeats software
distribution.
1. To what extent?
2. Let say this is plain right. Then why some FFI bindings
package provides such binaries?
I know this is annoying, but for others dynamic libraries
binaries are provided.
Not just annoying. From a user perspective it's like ... DoA.
You might ask for bgfx to provide you with binaries with
automated builds.
No, they ship their makefile and are commited to a c/c++
ecosystem. We are breaking their "ways" by interfacing through
another tech. They should not even know we exist... we are the
leeches.
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.
This is exactly my point. You had the libs built, on your system,
in sync with the version of the binding you did. Why not push
them along and basta! Done once and for all ... at least for one
target.
Instead, every wanna be user has to figure out what tag of bgfx
was used for the particular DerelictBgfx tag he aims to build,
get equipped to make the original and suffer all the friction
that such endeavour entails. -Welcome to a nice D show case
project my friend.-
I guess I should add in the README that you have to build bgfx
yourself for time being to avoid being let down.
Well, if I may answer through symmetric concerns ... constituting
such a README should have been a matter of digitalmars.D.learn.
